Series bảo mật nhập môn – Insecure direct object references – Giấu đầu lòi đuôi

Stealing online information

Kì này, mình sẽ giới thiệu một lỗ hổng bảo mật khá “lạ” mang cái tên dài loằng ngoằng khó đọc: Insecure Direct Object References.

Lỗi gì mà tên dài rứa??

Lỗi này “lạ” ở chỗ nó nằm trong top 4 OWASP nhưng lại có rất ít tài liệu về nó. Nó cũng không nổi tiếng như XSS hay CSRF hay SQL Injection (Dù rank OWASP của nó cao hơn XSS hay CSRF nhiều).

Bản thân mình trước đây cũng chưa hề nghe báo chí hay tin tức gì nhắc tới lỗi này. Có thể là do chưa có vụ án nổi tiếng nào liên quan đến nó, hoặc do lỗi này có nhiều biến thể phức tạp chăng?

Nguyên nhân chính gây ra lỗ hổng này là sự bất cẩn của developer hoặc sysadmin (Gặp lỗi này là phải lôi thằng dev ra chém trước, sau đó chém tester).

Lỗ hổng này xảy ra khi chương trình cho phép người dùng truy cập tài nguyên (dữ liệu, file, thư mục, database) một cách bất hợp pháp, thông qua dữ liệu do người dùng cung cấp. Để dễ hiểu hơn, hãy đọc ví dụ phía dưới nhé.

Cách lợi dụng lỗ hổng

Rất tình cờ, mình phát hiện lỗi này khi đang giúp một thằng em test đồ án web bán hàng.

Trong mục “Quản lý đơn hàng”, URL của một đơn hàng sẽ có dạng như sau: http://shop.com/user/order/1230. Server sẽ đọc ID 1230 từ URL, sau đó tìm đơn hàng có ID 1230 trong database và đổ dữ liệu vào HTML.

Bắt chước hacker, mình “nghịch ngợm” một tí, thay 1230 bằng các giá trị từ 1 tới 2000. Hệ thống cứ thế mà đọc và hiển thị cho mình toàn bộ các đơn hàng có ID từ 1 tới 2000 (kể cả đơn hàng của các khách hàng khác). Tai hại chưa!

Lỗ hổng ở đây chính là: chương trình cho phép mình truy cập tài nguyên (đơn hàng của người khác) bất hợp pháp, thông qua dữ liệu (ID) mà mình cung cấp qua URL. Lẽ ra, chương trình phải check xem mình có quyền truy cập các dữ liệu này hay không.

Trong thực tế, hacker có thể dùng nhiều chiêu trò như: thay đổi URL, thay đổi param trong API, sử dụng tool để scan những tài nguyên không được bảo mật. Chiêu hack lotte cinema ngày xưa của mình cũng na ná như thế, thay id trong URL bằng username trong cookie.

Cách đây khoảng 1-2 tháng, có 1 vụ lùm xùm liên quan tới công ty X (Hình như là CGV), lộ tài khoản của 3 triệu người dùng. Chính lỗ hổng Insecure Direct Object References này đã giúp hacker (ở đây là thánh bảo mật Juno_okyo) lợi dụng và dò ra thông tin của 3 triệu người dùng đó.

(Bài viết gốc khá hay ở đây: https://junookyo.blogspot.com/2016/10/ro-ri-3-trieu-thong-tin-ca-nhan.html).

Có một vài vụ việc hi hữu, hacker scan được git repository nằm trên server. Truy cập git, hắn lấy được username, password của database và các thông tin quan trọng khác.

Bạn đừng nghĩ là mình… hư cấu. Cách đây vài hôm, git của vietnamwork vẫn nằm public chễm chệ tại vietnamwork.com/.git/, không bảo mật gì! May mà gặp hacker “có tâm” đi ngang qua nên chưa có gì đáng tiếc xảy ra.

Cách phòng chống

Một số biện pháp phòng chống:

• Test cẩn thận – Nguyên nhân gây ra lỗi thường là do sự bất cẩn của developer. Tuy nhiên, nếu để sản phẩm bị lỗi thì đây là lỗi của tester. Đây là lỗi nằm trong code, do đó tester phải chịu trách nhiệm nếu để lỗi này xảy đến với người dùng.
• Bảo vệ dữ liệu “nhảy cảm” – Với những dữ liệu “nhạy cảm” như source code, config, database key, cần hạn chế truy cập. Cách tốt nhất là chỉ cho phép các IP nội bộ truy cập các dữ liệu này, hacker khỏi táy máy.
• Quan trọng nhất: Kiểm tra chặt chẽ quyền truy cập của user – Hãy thử xem tiki giải quyết vấn đề này như thế nào? Đơn hàng trên tiki.vn có dạng: https://tiki.vn/sales/order/view?code=33598178

• Dễ thấy, tiki để id của đơn hàng trong URL. tuy nhiên, khi mình thử thay đối id của đơn hàng thì tiki redirect mình lại trang https://tiki.vn/sales/order/history. Bảo mật có tâm là phải như thế!.
• Tránh để lộ key của đối tượng –  Trong các trường hợp đã nêu, id của đối tượng là số int, do đó hacker có thể đoán ra id của các đối tượng khác. Nhằm phòng tránh việt này, ta có thể mã hoá id, dùng GUID để làm id. Hacker không thể nào dò ra ID của đối tượng khác được.

Một số nguồn tham khảo thêm:

• https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References
• http://lockmedown.com/secure-from-insecure-direct-object-reference/
• https://codedx.com/insecure-direct-object-references/

Techtalk via toidicodedao