Bài viết & Thông báo
Cập nhật bài viết và thông báo mới nhất từ khoa An toàn Thông tin
2 kết quả#IDOR
blogsLỗ hổng IDOR không chỉ là lỗi kiểm tra id, mà là thất bại của tư duy phân quyền theo tài nguyên
IDOR không chỉ là lỗi đổi một ID trong URL mà là biểu hiện trực tiếp của Broken Access Control khi hệ thống truy xuất tài nguyên dựa trên object reference do client cung cấp nhưng không ràng buộc quyền thực tế của caller trên resource đó. Muốn xử lý tận gốc, ứng dụng phải chuyển từ tư duy kiểm tra chức năng đơn thuần sang authorization theo tài nguyên, kết hợp ownership, tenant boundary, ACL, kế thừa quyền, kiểm soát ở tầng service, repository và database để chặn truy cập trái phép một cách nhất quán.
blogsCùng xem, khi AI tham gia viết code, năng lực thiết kế mới quyết định hệ thống an toàn đến đâu (Opaque ID Design)
AI đang giúp lập trình viên tạo API nhanh hơn, nhưng cũng đang làm lộ rõ khoảng cách giữa viết được mã và hiểu được hệ thống mình đang xây. Một ví dụ điển hình là việc nhiều ứng dụng vẫn công khai primary key của cơ sở dữ liệu ra ngoài endpoint, từ đó mở đường cho lỗi tham chiếu đối tượng trực tiếp không an toàn (Insecure Direct Object Reference, IDOR). Định danh mờ (Opaque ID) là một quyết định thiết kế hữu ích để giảm khả năng suy diễn và enumeration, nhưng giá trị thật của nó chỉ xuất hiện khi người làm hiểu đúng bản chất, tránh các anti pattern, và đặt nó trong bức tranh tổng thể của authorization, validation, logging, transaction, cache, và kiểm soát rủi ro toàn hệ thống. Trong thời đại AI, lợi thế không còn nằm ở tốc độ sinh mã, mà nằm ở chiều sâu nhận thức về hậu quả thiết kế.