Authorization Logic Review trong pentest web thời AI

Lỗi authorization thường không nằm ở bước đăng nhập, mà ở chỗ hệ thống quên hỏi "user này có được làm việc này với object này không?". AI như Claude Code giúp pentester vẽ bản đồ và mở rộng hypothesis nhanh hơn nhiều, nhưng kiểm chứng và kết luận vẫn là việc của con người.

Khi mọi thứ “trông có vẻ đúng”

Trong pentest web, có một nhóm lỗi khá “khó chịu”: nhìn bên ngoài thì mọi thứ có vẻ đúng. Người dùng đăng nhập được, UI hiển thị đúng theo quyền, những nút không được phép thì bị ẩn đi. Nhưng khi kiểm tra kỹ hơn, đặc biệt là ở tầng API hoặc business logic, ta lại phát hiện người dùng vẫn có thể làm những việc mà họ không nên được làm.

Đó là nhóm vấn đề liên quan đến Authorization Logic.

• Nói đơn giản, authentication là câu hỏi: “Bạn là ai?”
• Còn authorization là câu hỏi: “Với danh tính đó, bạn được phép làm gì?”

Rất nhiều lỗi bảo mật không nằm ở bước đăng nhập. User đăng nhập hợp lệ, session hợp lệ, token cũng hợp lệ. Vấn đề nằm ở chỗ hệ thống không kiểm tra đúng quyền của user đó khi họ truy cập dữ liệu, sửa thông tin, gọi API, export file, thay đổi setting hoặc thực hiện một hành động nhạy cảm nào đó.

Vì vậy, Authorization Logic Review luôn là một phần rất đáng đầu tư trong pentest web.

Vì sao authorization khó test?

Authorization thường không nằm gọn trong một chỗ. Nó có thể rải rác ở nhiều tầng:

Chính vì vậy, nếu chỉ test theo luồng bình thường trên UI thì rất dễ bỏ sót.

Có những lỗi chỉ xuất hiện khi ta đổi một id, gọi trực tiếp một API bị ẩn trên giao diện, replay request bằng role khác, sửa request body, hoặc thử chuyển trạng thái workflow sai thứ tự.

Ví dụ:

• User A xem được dữ liệu của User B bằng cách đổi recordId.
• Member thường gọi được API chỉ dành cho admin.
• Người có quyền thấp tự nâng quyền của mình lên mức cao hơn.
• User không có quyền export nhưng vẫn gọi được endpoint export.
• Bulk update chỉ check quyền ở object đầu tiên, sau đó áp dụng cho toàn bộ danh sách.
• Workflow đã bị reject nhưng vẫn gọi được API approve.

Những lỗi kiểu này thường không dễ tìm bằng scanner. Scanner có thể hỗ trợ, nhưng nó không hiểu đầy đủ logic nghiệp vụ, vai trò người dùng, quyền động và impact thật sự của hệ thống.

Đây là lúc AI, ví dụ như Claude Code, có thể hỗ trợ rất tốt. Nhưng theo mình, AI nên là công cụ giúp điều tra nhanh hơn, không phải người thay pentester đưa ra kết luận cuối cùng.

Cách tiếp cận: con người dẫn dắt, AI tăng tốc

Một hướng làm hợp lý là: human-led, AI-assisted.

Pentester vẫn là người giữ vai trò trung tâm: hiểu scope, chọn giả thuyết, test thủ công, đánh giá impact và chốt kết luận. AI hỗ trợ các phần tốn thời gian như đọc code, map endpoint, lần theo luồng xử lý, tìm permission check, so sánh các flow tương tự và gợi ý biến thể test.

Nói ngắn gọn:

AI không thay thế manual pentest. AI giúp manual pentest có bản đồ tốt hơn, nhiều giả thuyết hơn và bằng chứng rõ ràng hơn.

Với Authorization Logic Review, có thể đi theo flow sau.

Quy trình 7 bước

Mỗi bước được đánh dấu ai là người dẫn: 🧑 pentester, 🤖 AI hỗ trợ.

1. Xác định role và tài sản cần bảo vệ 🧑

Trước khi bắn request hay đọc code, nên hiểu hệ thống có những role nào.

Ví dụ:

• Role:

  • Anonymous user
  • Normal user
  • Team member
  • Project admin
  • App admin
  • System admin
  • Guest user
  • API token
  • Integration user

Sau đó xác định những object hoặc chức năng quan trọng:

• Tài sản:

  • User profile
  • Project/team/organization
  • Record/document/file
  • Comment/message
  • Workflow request
  • Setting/configuration
  • API token/credential
  • Exported data
  • Audit log

Bước này nên do con người dẫn dắt, vì cần hiểu bối cảnh sản phẩm. Không phải màn hình nào cũng quan trọng như nhau. Có khi một trang setting nhỏ lại nhạy cảm hơn rất nhiều so với một trang dữ liệu lớn, nếu nó cho phép thay đổi permission, webhook, plugin, script hoặc API token.

2. Dùng AI để map attack surface 🤖

Sau khi đã có scope, có thể dùng Claude Code để đọc source và tạo bản đồ authorization.

Thay vì hỏi chung chung “hệ thống này có lỗi không?”, nên hỏi theo hướng cụ thể hơn:

Map all routes/endpoints related to project settings.

Map all routes/endpoints related to project settings.
For each endpoint, identify:
- required role or permission
- object ownership check
- service/controller involved
- sensitive action
- file:line evidence

Hoặc:

Find all places where permission is checked for updating records.
Compare single update, bulk update, import, and API update flows.
Point out inconsistent authorization checks with file:line evidence.

AI rất hữu ích ở bước này vì nó có thể đọc nhiều file nhanh, nối route với controller, controller với service, rồi lần tiếp xuống repository hoặc policy helper.

Output tốt nhất nên là một bảng rõ ràng:

Bảng này giúp pentester nhìn nhanh được chỗ nào đáng kiểm tra trước.

3. Test theo hypothesis, đừng test lan man 🧑

Authorization test rất dễ bị rộng. Nếu không có giả thuyết rõ ràng, ta có thể test rất nhiều request nhưng không biết đang tìm gì.

Một vài hypothesis đáng thử:

• Endpoint này check role admin nhưng không check object ownership.
• UI ẩn chức năng nhưng API vẫn gọi trực tiếp được.
• Bulk action chỉ check quyền trên một item.
• Export dùng query khác với màn hình list nên có thể leak data.
• User có quyền cấu hình app có thể tự nâng quyền của mình.
• Workflow transition không kiểm tra trạng thái hiện tại.
• API token có scope rộng hơn quyền của user tạo ra nó.

AI có thể giúp gợi ý hypothesis, nhưng pentester nên là người chọn cái nào đáng test dựa trên rủi ro thật.

4. Manual test vẫn là phần quan trọng nhất 🧑

Đây là phần không nên bỏ qua.

Sau khi có bản đồ và hypothesis, pentester cần test thật bằng browser, Burp, Postman hoặc script nhỏ. Nên chuẩn bị ít nhất hai account với quyền khác nhau:

• User A: có quyền hợp lệ
• User B: không có quyền với object đó
• Admin hoặc manager
• Low-privileged user
• User thuộc team/project khác

Một test authorization cơ bản có thể làm như sau:

• Đăng nhập bằng user có quyền và thực hiện action hợp lệ.
• Capture request.
• Đổi sang user ít quyền hơn.
• Replay request hoặc thay object id.
• Quan sát response, dữ liệu, log và UI.
• Xác nhận xem hành động có thật sự xảy ra không.

Điểm quan trọng là không chỉ nhìn status code. Có trường hợp API trả 200 OK nhưng dữ liệu không đổi. Ngược lại, cũng có trường hợp API báo lỗi nhưng dữ liệu đã bị thay đổi một phần. Có khi response bị chặn, nhưng background job vẫn chạy.

Manual test giúp xác nhận hành vi thật của hệ thống, điều mà AI không thể tự đảm bảo nếu chỉ đọc code.

5. Dùng AI để mở rộng biến thể 🤖

Khi đã thấy một dấu hiệu nghi ngờ, AI có thể giúp mở rộng rất nhanh.

Ví dụ, nếu phát hiện một endpoint update thiếu object ownership check, có thể hỏi Claude Code:

Find other endpoints using the same service method or same permission helper.
List similar update/delete/export/import flows that may share this issue.
Prioritize by sensitive impact.

Hoặc:

This endpoint checks project role but not record ownership.
Search for similar patterns across controllers and services.
Return only candidates with file:line evidence and why they are risky.

Cách này giúp biến một bug đơn lẻ thành một review có hệ thống. Không chỉ dừng lại ở “endpoint này có lỗi”, mà còn kiểm tra xem cùng một pattern có xuất hiện ở module khác không.

6. Root cause cần rõ ràng 🧑 + 🤖

Một report authorization tốt không nên chỉ viết “thiếu kiểm tra quyền”. Nên chỉ ra thiếu ở đâu và vì sao.

Ví dụ:

• Controller chỉ check user đã đăng nhập.
• Service check role nhưng không check object thuộc user/team/project hiện tại.
• Query lấy object theo id, nhưng không lọc theo tenant_id.
• Bulk action validate permission trước khi expand danh sách object.
• Export dùng repository khác nên bỏ qua permission filter.
• Workflow transition không validate current state.
• Admin setting cho phép user thay đổi chính quyền của mình.

AI rất hữu ích ở phần này vì có thể lần theo code path và chỉ ra nơi logic bị thiếu hoặc không nhất quán.

Tuy nhiên, vẫn cần con người review lại. Có những hệ thống dùng middleware, decorator, policy engine hoặc convention riêng. Nếu chỉ đọc một đoạn code đơn lẻ, AI có thể kết luận hơi vội.

7. Impact phải gắn với kịch bản thật 🧑

Authorization bug chỉ thật sự thuyết phục khi mô tả được impact rõ ràng.

Không nên chỉ dừng ở câu “user có thể bypass permission”. Cần trả lời cụ thể hơn:

• Ai có thể khai thác?
• Cần điều kiện gì?
• Dữ liệu nào bị ảnh hưởng?
• Có thể đọc, sửa, xóa hay chỉ gây lỗi?
• Ảnh hưởng một object hay nhiều object?
• Có leo quyền không?
• Có khai thác được từ UI không, hay cần gọi API trực tiếp?
• Có log/audit không?
• Có khôi phục được không?

Ví dụ, “user sửa được title của record người khác” là một mức impact. Nhưng “app admin có thể tự cấp full quyền, sau đó thêm plugin/script/API token để kiểm soát toàn bộ app” là một mức khác hẳn.

Đây là phần con người phải giữ vai trò chính. AI có thể giúp viết scenario, nhưng pentester phải đánh giá impact dựa trên sản phẩm thật.

Checklist nhanh khi review authorization

Checklist này không thay thế tư duy pentest, nhưng giúp tránh bỏ sót những bề mặt rất hay có lỗi.

Kết luận

Authorization Logic Review là một trong những phần đáng làm nhất khi pentest web, vì nó đi thẳng vào câu hỏi: người dùng thật sự được phép làm gì trong hệ thống?

Trong thời AI, cách làm hiệu quả không phải là để AI tự “quét” rồi tin ngay vào kết luận. Cách tốt hơn là để con người dẫn dắt: hiểu sản phẩm, đặt giả thuyết, test thủ công, đánh giá impact và chịu trách nhiệm với kết luận cuối cùng.

AI như Claude Code nên được dùng để tăng tốc những phần tốn công: đọc code, map endpoint, tìm permission check, so sánh flow, mở rộng biến thể và chuẩn hóa bằng chứng.

Nếu làm đúng, AI không làm pentest hời hợt hơn. Ngược lại, nó giúp pentester có thêm thời gian cho phần quan trọng nhất: suy nghĩ kỹ hơn, kiểm chứng chắc hơn và đưa ra kết luận có trách nhiệm hơn.

Tài liệu tham khảo

1. OWASP Top 10: A01 Broken Access Control - nền tảng để giải thích vì sao lỗi phân quyền là nhóm rủi ro rất phổ biến và nghiêm trọng.

2. OWASP Web Security Testing Guide: Authorization Testing - tham khảo flow test authorization/bypass permission.

3. OWASP WSTG: Testing for Insecure Direct Object References - dùng cho phần IDOR/BOLA, đổi object id, truy cập dữ liệu người khác.

4. OWASP ASVS V4: Access Control - checklist chuẩn để review access control ở tầng thiết kế và implementation.

5. OWASP Authorization Cheat Sheet - best practices như deny by default, least privilege, kiểm tra quyền ở trusted service layer.

6. OWASP API Security Top 10: API1 Broken Object Level Authorization - rất sát với lỗi user truy cập object không thuộc quyền của mình.

7. OWASP API Security Top 10: API3 Broken Object Property Level Authorization - dùng cho case user đọc/sửa field/property không được phép.

8. OWASP API Security Top 10: API5 Broken Function Level Authorization - dùng cho case user thường gọi được chức năng admin hoặc chức năng nhạy cảm.

9. PortSwigger Web Security Academy: Access Control Vulnerabilities - ví dụ thực hành rất dễ hiểu về access control, privilege escalation, IDOR.

10. MITRE CWE-862: Missing Authorization - mapping cho lỗi thiếu kiểm tra quyền.

11. MITRE CWE-863: Incorrect Authorization - mapping cho lỗi có kiểm tra quyền nhưng logic kiểm tra sai.

12. Claude Code Documentation - tham khảo phần sử dụng Claude Code như công cụ hỗ trợ đọc code, phân tích luồng và tăng tốc review.