Insecure Direct Object References (IDOR) là lỗ hổng bảo mật xảy ra khi ứng dụng cấp quyền hạn trực tiếp cho các đối tượng dựa vào dữ liệu input của người dùng đưa vào. Và nhờ điều này những hacker cố gắng bỏ qua phân quyền và access trực tiếp vào tài nguyên ví dụ như record hoặc database.
Các bài viết liên quan:
- Testing lỗ hổng bảo mật Weak Security Question Answer
- Testing lỗ hổng bảo mật Weak Password Policy
- Testing lỗ hổng Browser Cache Weaknesses
- Testing Security – kiểm tra quy trình đăng ký tài khoản
- Testing security – Role
Mục tiêu kiểm tra Insecure Direct Object References
Xác định các điểm mà các tham chiếu đối tượng có thể xảy ra.
Đánh giá các biện pháp kiểm soát truy cập và liệu chúng có dễ bị IDOR tấn công hay không.
Làm thế nào để kiểm tra Insecure Direct Object References
Để kiểm tra lỗ hổng này, trước tiên người kiểm tra cần phải vạch ra tất cả các vị trí trong ứng dụng nơi đầu vào của người dùng được sử dụng để tham chiếu trực tiếp các đối tượng. Ví dụ: các vị trí nơi đầu vào của người dùng được sử dụng để truy cập hàng cơ sở dữ liệu, tệp, các trang ứng dụng và hơn thế nữa. Tiếp theo, người kiểm tra nên sửa đổi giá trị của tham số được sử dụng để tham chiếu đến các đối tượng và đánh giá xem liệu có thể truy xuất các đối tượng thuộc về người dùng khác hay không hoặc bỏ qua ủy quyền.
Cách tốt nhất để kiểm tra các tham chiếu đối tượng trực tiếp là có ít nhất hai (thường nhiều hơn) người dùng để bao gồm các đối tượng và chức năng được sở hữu khác nhau. Ví dụ: hai người dùng, mỗi người có quyền truy cập vào các đối tượng khác nhau (chẳng hạn như thông tin mua hàng, tin nhắn riêng tư, v.v.) và (nếu có liên quan) người dùng có các đặc quyền khác nhau (ví dụ: người dùng quản trị viên) để xem liệu có tham chiếu trực tiếp đến chức năng ứng dụng hay không. Bằng cách có nhiều người dùng, người kiểm tra tiết kiệm thời gian kiểm tra quý giá trong việc đoán các tên đối tượng khác nhau vì anh ta có thể cố gắng truy cập các đối tượng thuộc về người dùng khác.
Dưới đây là một số tình huống điển hình cho lỗ hổng bảo mật này và các phương pháp kiểm tra cho từng tình huống:
Giá trị của một tham số được sử dụng trực tiếp để truy xuất bản ghi cơ sở dữ liệu
Yêu cầu mẫu:
http://foo.bar/somepage?invoice=12345
Trong trường hợp này, giá trị của tham số hóa đơn được sử dụng làm chỉ số trong bảng hóa đơn trong cơ sở dữ liệu. Ứng dụng nhận giá trị của tham số này và sử dụng nó trong một truy vấn đến cơ sở dữ liệu. Sau đó, ứng dụng sẽ trả về thông tin hóa đơn cho người dùng.
Vì giá trị của hóa đơn được đưa trực tiếp vào truy vấn, bằng cách sửa đổi giá trị của tham số, bạn có thể truy xuất bất kỳ đối tượng hóa đơn nào, bất kể hóa đơn đó thuộc về người dùng nào. Để kiểm tra trường hợp này, người kiểm tra phải lấy mã định danh của một hóa đơn thuộc về một người dùng thử nghiệm khác (đảm bảo rằng anh ta không phải xem thông tin này theo logic nghiệp vụ của ứng dụng), và sau đó kiểm tra xem liệu có thể truy cập các đối tượng mà không được phép hay không.
Giá trị của một tham số được sử dụng trực tiếp để thực hiện một hoạt động trong hệ thống
Yêu cầu mẫu:
http://foo.bar/changepassword?user=someuser
Trong trường hợp này, giá trị của tham số người dùng được sử dụng để cho ứng dụng biết nó nên thay đổi mật khẩu cho người dùng nào. Trong nhiều trường hợp, bước này sẽ là một phần của trình hướng dẫn hoặc thao tác nhiều bước. Trong bước đầu tiên, ứng dụng sẽ nhận được yêu cầu nêu rõ mật khẩu của người dùng sẽ được thay đổi và trong bước tiếp theo, người dùng sẽ cung cấp mật khẩu mới (không yêu cầu mật khẩu hiện tại).
Tham số người dùng được sử dụng để tham chiếu trực tiếp đến đối tượng của người dùng mà thao tác thay đổi mật khẩu sẽ được thực hiện. Để kiểm tra trường hợp này, người kiểm tra nên cố gắng cung cấp tên người dùng thử nghiệm khác với tên người dùng hiện đang đăng nhập và kiểm tra xem có thể sửa đổi mật khẩu của người dùng khác hay không.
Giá trị của một tham số được sử dụng trực tiếp để truy xuất tài nguyên hệ thống tệp
Yêu cầu mẫu:
http://foo.bar/showImage?img=img00011
Trong trường hợp này, giá trị của tham số tệp được sử dụng để cho ứng dụng biết người dùng định truy xuất tệp nào. Bằng cách cung cấp tên hoặc mã định danh của một tệp khác (ví dụ: tệp = image00012.jpg), kẻ tấn công sẽ có thể lấy các đối tượng thuộc về người dùng khác.
Để kiểm tra trường hợp này, người kiểm tra phải lấy một tham chiếu mà người dùng không được phép truy cập và cố gắng truy cập nó bằng cách sử dụng nó làm giá trị của tham số tệp. Lưu ý: Lỗ hổng này thường bị khai thác cùng với lỗ hổng truyền qua thư mục / đường dẫn (xem Kiểm tra kiểm tra đường dẫn)
Giá trị của một tham số được sử dụng trực tiếp để truy cập chức năng của ứng dụng
Yêu cầu mẫu:
http://foo.bar/accessPage?menuitem=12
Trong trường hợp này, giá trị của tham số menuitem được sử dụng để cho ứng dụng biết mục menu nào (và do đó là chức năng ứng dụng) mà người dùng đang cố gắng truy cập. Giả sử người dùng được cho là bị hạn chế và do đó chỉ có sẵn các liên kết để truy cập vào các mục menu 1, 2 và 3. Bằng cách sửa đổi giá trị của tham số menuitem, có thể bỏ qua ủy quyền và ngừng chức năng ứng dụng bổ sung. Để kiểm tra trường hợp này, người kiểm tra xác định vị trí nơi chức năng ứng dụng được xác định bằng cách tham chiếu đến một mục menu, ánh xạ các giá trị của các mục menu mà người dùng thử nghiệm đã cho có thể truy cập, sau đó thử các mục menu khác.
Trong các ví dụ trên, chỉ cần sửa đổi một tham số là đủ. Tuy nhiên, đôi khi tham chiếu đối tượng có thể bị tách thành nhiều hơn một tham số và việc kiểm tra phải được điều chỉnh cho phù hợp.
