Kiểm tra phân quyền web app và API: Từ ma trận quyền đến IDOR

Phân quyền khác xác thực như thế nào?

Xác thực trả lời ai đang gửi request. Phân quyền trả lời danh tính đó có được gọi chức năng này, trên đối tượng này, với các field này và trong tenant này hay không. Một API có đăng nhập, token hợp lệ và giao diện ẩn nút quản trị vẫn có thể hở quyền nếu server chỉ tin ID hoặc role do client gửi lên.

Khi kiểm tra phân quyền web app và API, không nên chỉ thử một tài khoản admin rồi kết luận luồng hoạt động. Cần có anonymous, người dùng thường, quản lý, quản trị và ít nhất hai tài khoản hoặc tổ chức độc lập nếu hệ thống có nhiều tenant. Mỗi request nhạy cảm phải được kiểm tra bằng danh tính đúng và những danh tính không được phép.

Phạm vi bài này tập trung vào object, function, property và tenant boundary theo các nhóm rủi ro OWASP API Security 2023. Đây là checklist tự kiểm có ngữ cảnh; chỉ thực hiện active test trên tài sản, tài khoản và môi trường đã được cho phép.

• ✓Authentication: danh tính, phiên, token, issuer, audience và trạng thái thu hồi.
• ✓Authorization: vai trò, hành động, object, field, quan hệ sở hữu và tenant.
• ✓Enforcement: quyết định phía server ở mỗi request, không dựa vào UI hoặc dữ liệu client.
• ✓Evidence: request, danh tính thử, kết quả mong đợi, response và side effect thực tế.

Một request trả về 403 chưa chứng minh phân quyền an toàn nếu dữ liệu đã bị đọc, sửa hoặc đẩy sang hệ thống downstream trước đó.

Lập inventory danh tính, vai trò, object và tenant

Trước khi test phân quyền API, lập danh sách các actor thật: khách chưa đăng nhập, khách hàng, nhân viên, quản lý, admin, service account, webhook và job nền. Ghi rõ cách mỗi actor nhận quyền, quyền có thời hạn hay không, và điều gì xảy ra khi người dùng rời nhóm hoặc tenant.

Tiếp theo, liệt kê object và luồng có giá trị: hồ sơ, đơn hàng, hóa đơn, tệp, báo cáo, API key, lời mời, export, cấu hình và hành động phê duyệt. Đừng bỏ qua endpoint list, search, batch, download, GraphQL resolver, WebSocket hoặc URL ký sẵn; dữ liệu thường bị lộ qua các đường phụ thay vì trang chi tiết chính.

Với hệ thống SaaS, tenant không chỉ là một cột organization_id. Boundary có thể nằm trong cache key, object storage path, queue message, search index, report export và kết nối dịch vụ bên thứ ba. Inventory phải theo dữ liệu xuyên suốt luồng, không chỉ dừng ở route HTTP.

• ✓Danh tính: anonymous, user, manager, admin, support, service account và job nền.
• ✓Object: bản ghi, tệp, báo cáo, secret, cấu hình, lời mời và export.
• ✓Quan hệ: owner, thành viên nhóm, người được chia sẻ, người phê duyệt và tenant.
• ✓Kênh truy cập: UI, REST, GraphQL, mobile, webhook, queue và object storage.

Tạo ma trận role × action × object/data

Ma trận phân quyền biến câu mô tả mơ hồ thành điều kiện có thể test. Mỗi hàng là vai trò hoặc quan hệ; mỗi cột là hành động trên object: list, read, create, update, delete, approve, export, share hoặc administer. Với mỗi ô, ghi allow hoặc deny cùng điều kiện về owner, tenant, trạng thái và field được phép.

Không nên chỉ dùng role. Một user có thể đọc hồ sơ của chính mình nhưng không đọc user khác; manager được duyệt đơn của nhóm nhưng không duyệt đơn do chính mình tạo; support được xem trạng thái nhưng không xem thông tin thanh toán. Các điều kiện này cần trở thành test case, không nằm riêng trong tài liệu nghiệp vụ.

Từ mỗi ô allow, tạo ít nhất một positive test. Từ mỗi boundary, tạo negative test tương ứng: sai user, sai tenant, sai trạng thái, role thấp hơn, field ngoài phạm vi hoặc hành động vượt quyền. Lưu ma trận cùng endpoint inventory để chạy lại khi API, role hoặc workflow thay đổi.

• ✓Mỗi rule ghi actor, action, object, condition và field scope.
• ✓Mỗi quyền cho phép có positive test; mỗi boundary có negative test.
• ✓Kiểm tra deny by default cho route và hành động mới chưa khai báo.
• ✓Đưa các case ổn định vào CI để tạo authorization regression test.

Test lỗ hổng IDOR và BOLA theo chiều ngang

IDOR thường mô tả tình huống ứng dụng nhận ID do client kiểm soát rồi truy cập object mà không kiểm tra quyền. Trong API, OWASP gọi nhóm rộng hơn là Broken Object Level Authorization, hay BOLA. Cách test cơ bản là tạo object bằng tài khoản A, đăng nhập tài khoản B cùng role, rồi thay ID, parent ID, query, body hoặc path để thử đọc, sửa và xóa object của A.

Đừng chỉ thử endpoint GET /items/{id}. Kiểm tra list và search có lọc đúng owner/tenant, export có trộn dữ liệu, file download có kiểm tra quyền, batch endpoint có xác minh từng object, và nested route có kiểm tra cả parent lẫn child. Với object đã xóa, archived hoặc chuyển owner, test lại quyền ở trạng thái mới.

UUID hoặc ID ngẫu nhiên làm việc đoán ID khó hơn nhưng không phải kiểm soát phân quyền. Nếu link bị lộ qua log, referrer, email hoặc lịch sử trình duyệt, kẻ không có quyền vẫn có thể dùng ID. Policy phía server phải truy vấn object trong đúng scope của người gọi hoặc đánh giá quyền trên object đã tải.

• ✓Cross-user: cùng role nhưng thay ID để truy cập object của người khác.
• ✓Cross-parent: giữ child ID nhưng thay organization, project hoặc account ID.
• ✓List/search/export/file: kiểm tra lọc, tổng số, metadata và URL tải xuống.
• ✓Batch/GraphQL: xác minh quyền cho từng node, object và resolver.

Test quyền chức năng và field nhạy cảm

Broken Function Level Authorization xảy ra khi người dùng biết hoặc đoán được function dành cho role cao hơn, chẳng hạn route admin, thao tác duyệt, hoàn tiền, khóa tài khoản hoặc export toàn bộ. Thử gọi function đó bằng role thấp, thay HTTP method, dùng phiên bản API cũ và gọi endpoint trực tiếp thay vì qua UI.

Broken Object Property Level Authorization liên quan đến field. Response có thể trả thừa giá vốn, role, token, thông tin nội bộ hoặc dữ liệu cá nhân; request có thể cho phép mass assignment để tự đổi owner, price, status, approved hoặc isAdmin. Kiểm tra cả field ẩn khỏi UI và field lồng trong object hoặc array.

Biện pháp đáng tin cậy là allowlist field theo hành động và policy, dùng DTO hoặc schema rõ ràng, rồi kiểm tra lại object sau request. Trả 200 nhưng âm thầm nhận field vượt quyền là lỗi; trả 403 nhưng đã đổi database trước đó cũng là lỗi.

• ✓Role thấp gọi route admin, approve, refund, export hoặc user management.
• ✓Đổi method, content type, API version hoặc đường dẫn tương đương.
• ✓Thêm field owner, tenant, role, price, status, approval hoặc internal note.
• ✓So sánh response schema và dữ liệu lưu thực tế theo từng role.

Kiểm tra tenant isolation end-to-end

Tenant isolation testing cần ít nhất hai tenant với dữ liệu thử riêng. Tạo object trong tenant A, sau đó dùng danh tính tenant B thử truy cập qua path, query, body, header, GraphQL variable, file key và link chia sẻ. Lặp lại với user có cùng role để tránh nhầm quyền role với boundary tổ chức.

Kiểm tra cả dữ liệu gián tiếp: autocomplete, bộ đếm, analytics, email, notification, audit log, search index, cache, export và background job. Một response không lộ nội dung nhưng trả đúng tên file, số lượng bản ghi hoặc thời gian hoạt động của tenant khác vẫn có thể rò metadata.

Service-to-service và support impersonation cần scope riêng. Token nội bộ không nên mặc nhiên đọc mọi tenant; chức năng hỗ trợ cần lý do, giới hạn thời gian và audit trail. Sau khi đổi thành viên, chuyển tenant hoặc thu hồi quyền, kiểm tra cache và token cũ không tiếp tục cấp quyền.

• ✓Dùng hai tenant và nhiều role với dữ liệu tổng hợp có thể nhận biết.
• ✓Thử boundary ở database, cache, search, file, queue và dịch vụ downstream.
• ✓Test thay đổi membership, tenant transfer, revoke và session/token còn sống.
• ✓Ghi log acting identity, tenant, object, action, decision và correlation ID.

Negative test, bằng chứng và kiểm tra side effect

Một test case tốt ghi rõ danh tính, tenant, role, endpoint, request, object, điều kiện trước test, kết quả mong đợi và kết quả thực tế. Với deny case, không chỉ so mã 401 hoặc 403; kiểm tra response body không lộ field và xác nhận database, queue, email, file hoặc webhook không có tác động trái phép.

Các test ổn định nên chạy tự động sau thay đổi policy, endpoint và schema. Automation đặc biệt hữu ích cho ma trận nhiều role và object, nhưng không tự hiểu toàn bộ điều kiện nghiệp vụ. Manual review vẫn cần cho workflow nhiều bước, quyền dẫn xuất, trạng thái hiếm và luồng support hoặc phê duyệt.

Log cần đủ để điều tra quyết định quyền mà không thu thập quá mức. Ghi acting identity, role, tenant, object type/ID phù hợp, action, allow/deny, policy version và correlation ID; không ghi token, secret hoặc payload nhạy cảm không cần thiết.

• ✓Có baseline positive test và negative control cho mỗi boundary quan trọng.
• ✓Kiểm tra response, database, queue, email, file và downstream side effect.
• ✓Tự động hóa regression test nhưng giữ manual review cho logic có ngữ cảnh.
• ✓Lưu bằng chứng tối thiểu, che dữ liệu nhạy cảm và gắn owner sửa lỗi.

Release gate, remediation và khi nào cần đánh giá độc lập

Trước release, ưu tiên sửa mọi đường dẫn cho phép cross-tenant, đọc hoặc sửa object không thuộc quyền, gọi function đặc quyền và ghi field nhạy cảm. Sau khi sửa, chạy lại đúng request ban đầu, negative control và một positive test để chắc chắn policy vừa chặn sai vừa không phá luồng hợp lệ.

Scanner có thể tìm endpoint, schema và một số mẫu phản hồi, nhưng thường không biết user nào sở hữu object, tenant nào là boundary hoặc hành động nào gây side effect. Vì vậy không nên dùng kết quả scan đơn lẻ để khẳng định phân quyền an toàn. Hệ thống nhiều tenant, dữ liệu nhạy cảm, thanh toán, quyền quản trị phức tạp hoặc API public nên có review dựa trên tài khoản thử và threat model cụ thể.

Friday Works thực hiện đánh giá bảo mật website, web app và API trong phạm vi được thống nhất, tập trung vào xác thực, phân quyền object/function/property, tenant isolation và luồng quan trọng. Đầu ra gồm bằng chứng tái hiện, mức ưu tiên, hướng khắc phục và retest trong phạm vi — không quảng cáo một lần scan là pentest toàn diện hay chứng nhận hệ thống tuyệt đối an toàn.

• ✓Chặn release với lỗi cross-tenant hoặc truy cập trái phép dữ liệu/chức năng quan trọng.
• ✓Retest đúng bằng chứng cũ và thêm positive test chống regression.
• ✓Ghi owner, thời hạn, rủi ro còn lại và quyết định go/no-go.
• ✓Cân nhắc đánh giá độc lập khi boundary hoặc tác động nghiệp vụ phức tạp.