Tình huống: API lộ đơn hàng của khách khác Trung cấp

Một researcher chỉ cần đổi con số trong URL là đọc được đơn của khách khác. Trong lúc sửa, team tìm ra lỗ thứ hai: user thường tự nâng mình lên admin. Bạn có bốn quyết định: chặn lỗ, khoanh vùng ai bị lộ, sửa thiết kế, và đóng sự cố.

• Câu hỏi cần trả lời ở mỗi bước: người gọi có quyền với object này, và với field này không?
• Điểm chỉ tính lựa chọn đầu tiên ở mỗi bước.

Tình huống

Đổi số trong URL là đọc được đơn của người khác

Bạn là backend lead của một shop online: 184.000 khách, khoảng 1,2 triệu đơn, ID đơn là số tăng dần. API viết bằng NestJS + PostgreSQL, access log giữ 90 ngày. Mỗi lựa chọn hiển thị ngay hậu quả trên các chỉ số.

Lỗ hổng authz còn mở1

Tra cứu đơn hoạt động100 %

Khách phải coi là có thể bị lộ184.000

Endpoint nhận ID chưa có test authz46

Bước 1/4 · Báo cáo từ security researcher

10:05 thứ Sáu, hộp thư security@ nhận email từ một researcher: đăng nhập bằng tài khoản của chính anh ta, gọi GET /api/orders/1048213 rồi đổi số cuối, API trả về đơn của khách khác: tên, số điện thoại, địa chỉ, món hàng. Bạn tái hiện được trong 2 phút.

lớp lỗi

BOLA / IDOR (OWASP API1:2023)

ID đơn

số tăng dần, đoán được

endpoint có từ

14 tháng trước

// orders.controller.ts
@UseGuards(JwtAuthGuard)              // chỉ kiểm tra token hợp lệ
@Get(':id')
get(@Param('id') id: string) {
  return this.orders.findById(id);     // SELECT * FROM orders WHERE id = $1
}

Bạn làm gì?

AĐổi ID đơn sang UUID v4 để không ai đoán được nữaBHotfix ngay: scope query theo người gọi, test bằng 2 tài khoản, deploy trong giờSELECT * FROM orders WHERE id = $1 AND customer_id = $2 -- $2 = req.user.id từ tokenCTắt hẳn GET /api/orders/{id} bằng feature flag cho tới khi có bản sửa chuẩnDThêm rate limit 10 request/phút cho endpoint, sửa code sau sprint

Chơi xong, đọc BOLA/IDOR để xem cách scope query theo actor và các endpoint list, bulk, export hay bị sót.