IDOR Và Cách Phát Hiện

Ngày Hôm nay mình xin chia sẻ cách cho các bạn làm sao để có thể phát hiện được lỗ hổng bảo mật IDOR vô cùng nguy hiểm.

Có thể có nhiều biến số trong ứng dụng như là id id,, pid, và uid. Mặc dù các giá trị này thường được xem là tham số HTTP, nhưng chúng có thể được tìm thấy trong các tiêu đề và cookie. Kẻ tấn công có thể truy cập, chỉnh sửa hoặc xóa bất kỳ đối tượng nào của người dùng khác bằng cách thay đổi các giá trị. Lỗ hổng này được gọi là IDOR.

IDOR tên đầy đủ của nó là Insecure Direct Object References là một trong những lỗ hổng có tuổi đời rất lâu rồi và nó là lỗ hổng nghiêm trọng với các hệ thống nếu gặp phải. và nó rất hay gặp ở các API. vậy IDOR nó là như thế nào?

Đầu tiên, ta cần hiểu luồng ứng dụng được phát triển bởi các nhà phát triển phần mềm. Tất cả các chức năng mô-đun và chức năng mô-đun phụ của chúng cần được hiểu khi người dùng đăng nhập vào ứng dụng web / di động. Điều quan trọng cần nhớ là lỗ hổng này cũng nghiêm trọng như XSS, CSRF trong kiểm tra bảo mật và là một loại lỗ hổng không dễ bị phát hiện (kiểm tra tự động hóa hoặc kiểm tra thủ công).

Trên website để quản lý các user, tài liệu, bài viết.. thì các lập trình viên hay quy định link để có thể view được user tài liệu hay bài viết đó là một ID trong cơ sở dữ liệu mỗi ID được sinh ra thường sẽ được gắn liền với 1 user nào đó và các user khác không có quyền thực thi trên ID đó.

Tuy nhiên bằng cách nào đó mà lập trình viên lại để ID một cách quá dễ đoán chỉ là số chạy từ 1 tới dương vô cực. Điều này tiềm ẩn nguy cơ bị lỗ hổng IDOR. Khi user truy vấn ID tăng tiến theo đúng quy trình dev đưa ra như hình sau

Thì dữ liệu vẫn được trả về và nó bao gồm các thông tin của user 1003 như vậy nó vô tình làm lộ thông tin user. dưới đây là một video demo về lỗ hổng này mức nghiêm trọng.

Kiểm tra lỗ hổng IDOR hiệu quả

Vậy làm sao để tôi có thể phát hiện được IDOR? cách đơn giản nhất là bạn hay nhìn các truy vấn api, web... xem có thông số nào có thể thay đổi được không nó thường là ID là số bạn nên đăng ký 2 tài khoản để so sánh sự khác nhau trong từng truy vấn xem những thay đổi đó có thể đổi cho nhau được không đúng ra là tài khoản a truy vấn giờ thành tài khoản b.... từ đó bạn sẽ biết được IDOR có tổn tại hay không...

Bạn có thể sử dụng tab HTTP History của Burp Suite để kiểm tra tất cả các yêu cầu. Tính năng HTTP History hiển thị tất cả lưu lượng giữa thiết bị (trình duyệt, điện thoại, máy tính bảng) và máy chủ của ứng dụng. Ngoài ra, bạn có thể sử dụng tính năng scope của Burp Suite để kiểm tra nhanh. Bởi vì tính năng scope có thể hữu ích để tạo danh sách mục tiêu và tính năng scope cho phép chỉ hiển thị dữ liệu có liên quan cho phạm vi thử nghiệm của bạn.

Khi kiểm tra lỗ hổng IDOR, về cơ bản, bạn cần thực hiện thực hiện tất cả các yêu cầu mà ứng dụng web / di động sẽ được tạo, yêu cầu. Bởi vì nếu bạn đã thay đổi một cái gì đó trong ứng dụng, có thể tạo các yêu cầu khác bằng cách sử dụng trường hợp này. Nếu bạn có tất cả các yêu cầu API của ứng dụng như tệp WSDL, trang Swagger, v.v. và nó hoạt động, bạn thật may mắn! Bạn có thể sử dụng cái này và nó sẽ giúp bạn thuận tiện cho việc kiểm tra IDOR.

Một ví dụ được gặp trong một chương trình thanh toàn bằng thẻ tín dụng. Thẻ tín dụng được thêm khi mua hàng trong ứng dụng di động. Sau khi các yêu cầu được kiểm tra, có thể nghĩ rằng không có bất kỳ lỗ hổng nào. Nhưng khi mua lần thứ hai, màn hình lựa chọn thẻ tín dụng được nhìn thấy và lỗ hổng IDOR là tại thời điểm này. Khi chọn thẻ tín dụng ở đây, ứng dụng sẽ gửi id thẻ tín dụng đến máy chủ theo yêu cầu và yêu cầu này đã cung cấp để truy cập dữ liệu thẻ tín dụng của người dùng khác thay đổi id thẻ tín dụng.