Hóa đơn của ai: kiểm thử phân quyền qua một tình huống nhỏ

Một nút bị ẩn chưa bảo vệ được hóa đơn

Giả sử một cổng doanh nghiệp cho phép mỗi phòng ban xem hóa đơn của mình. Tài khoản phòng A không thấy liên kết đến hóa đơn phòng B trên giao diện. Điều đó mới chứng minh liên kết đã bị ẩn. Bài kiểm thử cần trả lời thêm: nếu yêu cầu đọc hóa đơn được gửi trực tiếp, máy chủ có kiểm tra quyền trên đúng tài nguyên không?

Đây là tình huống luyện tập với hai tài khoản và hóa đơn giả lập trong môi trường được phép. Ghi phạm vi trước: chức năng xem, tải tệp và sửa trạng thái nào được kiểm tra; tài khoản nào đại diện cho vai trò nào. Không cần dữ liệu thật để chứng minh sự khác biệt giữa có quyền và không có quyền.

Dựng ma trận quyền từ nghiệp vụ

Hỏi người phụ trách sản phẩm về quy tắc sở hữu: quyền đi theo người tạo, phòng ban hay tổ chức? Một nhân viên chuyển phòng có giữ quyền cũ không? Quản lý được xem tất cả hay chỉ được phê duyệt một số trạng thái? Các câu trả lời trở thành căn cứ đánh giá; tên vai trò đơn thuần thường không mô tả hết điều kiện.

Chuẩn bị hóa đơn của A, của B và một hóa đơn không tồn tại. Với mỗi tài khoản, ghi hành động được phép cùng kết quả mong đợi. Tách xem thông tin, tải tài liệu và cập nhật dữ liệu vì chúng có thể dùng các đường xử lý khác nhau. Một phép kiểm đạt ở trang chi tiết chưa bảo đảm đường tải tệp cũng được bảo vệ.

Đăng nhập từng tài khoản và chạy đường đi hợp lệ trước. Bước này xác nhận dữ liệu, quyền và môi trường đã được dựng đúng. Nếu tài khoản A không xem được cả hóa đơn của A, kết quả từ chối truy cập hóa đơn B chưa chứng minh quy tắc hoạt động. Cần tránh nhận một lỗi cấu hình chung thành thành công bảo mật.

Kiểm tra quyết định ở nơi dữ liệu được cấp

Trong phạm vi đã thống nhất, dùng yêu cầu đọc hợp lệ của A để kiểm tra phản hồi khi nhắm đến hóa đơn giả lập của B. Đối chiếu cả trạng thái phản hồi lẫn nội dung; mã lỗi không đủ nếu thân phản hồi vẫn chứa dữ liệu. Tiếp tục xem giao diện có lưu lại thông tin cũ sau khi đổi tài khoản hay không.

Với thao tác cập nhật, kiểm tra trạng thái dữ liệu sau yêu cầu bị từ chối. Thông báo “không có quyền” trên màn hình không bảo đảm phía máy chủ chưa thay đổi hóa đơn. Đối chiếu bằng tài khoản có quyền trong bộ dữ liệu thử. Mỗi kết quả nên gắn với hành động cụ thể, tránh gom mọi vấn đề thành một nhãn “lỗi đăng nhập”.

Thử thêm các thời điểm quyền thay đổi nếu chúng nằm trong yêu cầu: tài khoản bị thu hồi quyền, phiên hết hiệu lực hoặc người dùng chuyển vai trò. Ghi rõ thao tác nào cần đăng nhập lại theo thiết kế. Mục tiêu là xác nhận chính sách được thi hành nhất quán, không mặc định mọi cơ chế quản lý phiên đều phải có cùng hành vi.

Từ phát hiện đến bằng chứng có thể sửa

Một báo cáo hữu ích nêu tài khoản giả lập, quan hệ sở hữu, thao tác, dữ liệu mong đợi và dữ liệu thực nhận. Chỉ giữ phần phản hồi cần chứng minh, loại thông tin xác thực trước khi chia sẻ. Mô tả tác động bằng nghiệp vụ: nhân viên khác phòng đọc được tài liệu nào hoặc thay đổi được trạng thái nào. Điều đó giúp đội ưu tiên đúng mức.

Sau bản sửa, chạy lại trường hợp vi phạm lẫn đường hợp lệ và vai trò lân cận. Công cụ quét hoặc AI có thể mở rộng danh sách câu hỏi, nhưng không thay việc hiểu chính sách sở hữu. Kết luận nên giới hạn ở tài nguyên và hành động đã thử. Một ma trận nhỏ có bằng chứng thường đáng tin hơn tuyên bố toàn hệ thống đã an toàn sau một lượt quét.

Về nguồn tham khảo

Chủ đề tham khảo từ bộ AI Tester Skills. Bài viết và tình huống minh họa được biên soạn lại cho người đọc.