SQL Injection Mù - SQL injection khai thác Timebase

Vấn đáp

#

1. Điều gì tạo ra sự khác biệt giữa Time-Based SQL Injection và các kỹ thuật SQL injection khác? Hãy giải thích cách tin tặc lợi dụng độ trễ thời gian trong truy vấn SQL để trích xuất thông tin từ cơ sở dữ liệu, cũng như lý do phương pháp này đặc biệt hữu ích trong các kịch bản Blind SQL injection (khi ứng dụng web không trả về bất kỳ dữ liệu nào).

   Time-Based SQL Injection là kỹ thuật SQLi dựa vào độ trễ phản hồi của máy chủ thay vì dựa vào dữ liệu được trả về trực tiếp.

   Điểm khác biệt chính:

   • Với Union-Based SQLi, attacker cố lấy dữ liệu hiển thị trực tiếp trên trang.
   • Với Error-Based SQLi, attacker dựa vào thông báo lỗi SQL.
   • Với Boolean-Based Blind SQLi, attacker quan sát sự khác nhau giữa phản hồi đúng/sai.
   • Với Time-Based Blind SQLi, attacker quan sát thời gian phản hồi nhanh hay chậm để suy ra dữ liệu.

   Cách lợi dụng: attacker chèn điều kiện vào truy vấn SQL. Nếu điều kiện đúng, database bị ép “ngủ” vài giây; nếu sai, phản hồi bình thường. Ví dụ về mặt ý tưởng:

   1 2	Nếu ký tự đầu tiên của mật khẩu là 'a' thì delay 5 giây Ngược lại thì phản hồi ngay

   Nếu website phản hồi chậm, attacker suy ra điều kiện là đúng. Lặp lại nhiều lần với từng ký tự, attacker có thể trích xuất dần tên database, bảng, cột hoặc dữ liệu nhạy cảm.

   Phương pháp này đặc biệt hữu ích trong Blind SQL Injection vì ứng dụng không hiển thị dữ liệu, không báo lỗi, và phản hồi nhìn bề ngoài có thể giống nhau. Khi đó, thời gian phản hồi trở thành “kênh phụ” để rò rỉ thông tin.

2. Mô tả quá trình thực hiện một cuộc tấn công Time-Based SQL Injection vào một ứng dụng web có lỗ hổng. Các bước cốt lõi để tạo ra một truy vấn SQL nhằm gây ra độ trễ có chủ đích trong phản hồi của cơ sở dữ liệu là gì?

   1. Xác định điểm nhập liệu có thể bị SQLi, ví dụ parameter trong URL, form đăng nhập, ô tìm kiếm, cookie hoặc header.
   2. Kiểm tra khả năng gây delay bằng cách chèn một biểu thức SQL khiến database trì hoãn phản hồi, như SLEEP(), pg_sleep() hoặc WAITFOR DELAY tùy hệ quản trị CSDL.
   3. So sánh thời gian phản hồi:
   • Nếu request bình thường phản hồi trong 1 giây.
   • Request nghi ngờ SQLi phản hồi sau 5–10 giây.
   • Có khả năng ứng dụng đang thực thi phần SQL bị chèn.
   4. Tạo điều kiện đúng/sai kết hợp với delay, ví dụ về logic:

   1 2	Nếu điều kiện đúng → delay 5 giây Nếu điều kiện sai → không delay

   5. Trích xuất dữ liệu từng phần bằng cách đặt câu hỏi dạng đúng/sai, ví dụ:
   • Độ dài tên database có phải là 5 không?
   • Ký tự đầu tiên có phải là “a” không?
   • Ký tự thứ hai có phải là “d” không?
   6. Lặp lại quá trình cho đến khi suy ra được dữ liệu cần tìm.

Thực hành

#

1. Đầu tiên, chúng ta truy cập bài lab Blind SQL injection with time delays trên Web Security Academy của PortSwigger. Sau khi mở bài lab, trang web hiển thị giao diện cửa hàng với các danh mục sản phẩm như All, Food & Drink, Gifts, Lifestyle, Tech gifts và Toys & Games.

Mục tiêu của bài lab là khai thác lỗ hổng Blind SQL Injection bằng kỹ thuật Time-Based SQL Injection, tức là làm cho cơ sở dữ liệu phản hồi chậm có chủ đích để xác nhận rằng câu lệnh SQL đã bị chèn và được thực thi.

2. Sau khi bật Burp Suite và cấu hình trình duyệt đi qua proxy của Burp, chúng ta truy cập một danh mục bất kỳ trên trang web, ví dụ:

1

GET /filter?category=Toys+%26+Games HTTP/2

Burp Suite bắt được request gửi đến server. Trong request này, chúng ta có thể nhận thấy rằng có cookie TrackingId. Đây là giá trị do người dùng kiểm soát và có khả năng được ứng dụng sử dụng trong truy vấn SQL ở phía backend.

Ví dụ phần cookie trong request:

1

Cookie: TrackingId=<giá_trị_tracking_id>; session=<giá_trị_session>

Sau đó, chúng ta gửi request này sang tab Repeater để có thể chỉnh sửa payload và gửi lại nhiều lần nhằm quan sát phản hồi từ server.

3. Trong Burp Repeater, chúng ta tập trung kiểm thử vào tham số cookie TrackingId, vì đây là vị trí thường được ứng dụng dùng để theo dõi người dùng và có thể được lưu hoặc truy vấn trong cơ sở dữ liệu.

Ý tưởng khai thác là chèn thêm một đoạn SQL vào cuối giá trị TrackingId. Nếu backend thực thi đoạn SQL này, cơ sở dữ liệu sẽ bị yêu cầu “ngủ” trong một khoảng thời gian nhất định trước khi trả về phản hồi.

4. Vì mỗi hệ quản trị cơ sở dữ liệu sử dụng cú pháp delay khác nhau, chúng ta thử nhiều dạng payload khác nhau để xác định backend đang sử dụng loại database nào.

Payload dành cho SQL Server

1

'||WAITFOR DELAY '00:00:05'--

Payload này dùng cú pháp WAITFOR DELAY, thường gặp trong Microsoft SQL Server. Tuy nhiên, khi gửi request, thời gian phản hồi chỉ khoảng vài trăm mili giây, không có độ trễ đáng kể. Vì vậy, có thể kết luận backend không xử lý payload theo cú pháp SQL Server.

Payload dành cho MySQL

1

'||sleep(10)--

Payload này dùng hàm sleep(), thường gặp trong MySQL. Sau khi gửi request, phản hồi vẫn trả về rất nhanh, không có độ trễ 10 giây như mong đợi. Điều này cho thấy payload kiểu MySQL không phù hợp với backend của bài lab.

Payload dành cho PostgreSQL

1

'||pg_sleep(10)--

Payload này sử dụng hàm pg_sleep(), là hàm tạo độ trễ trong PostgreSQL. Khi chèn payload này vào cookie TrackingId và gửi request, server phản hồi chậm rõ rệt, khoảng hơn 10 giây. Đây là dấu hiệu cho thấy payload đã được thực thi thành công bởi cơ sở dữ liệu.

5. Phân tích payload

1

'||pg_sleep(10)--

Ý nghĩa của payload:

• Dấu ' dùng để đóng chuỗi hiện tại trong câu truy vấn SQL.
• Toán tử || dùng để nối chuỗi trong PostgreSQL.
• Hàm pg_sleep(10) yêu cầu database tạm dừng xử lý trong 10 giây.
• Dấu -- dùng để comment phần còn lại của câu truy vấn SQL, tránh lỗi cú pháp.

Khi server phản hồi chậm sau khi gửi payload này, điều đó chứng minh rằng giá trị cookie TrackingId đã được đưa vào câu truy vấn SQL mà không được xử lý an toàn. Vì ứng dụng không trả về dữ liệu database hay thông báo lỗi, chúng ta dựa vào thời gian phản hồi để xác nhận lỗ hổng. Đây chính là đặc điểm của Time-Based Blind SQL Injection.

6. Sau khi gửi request chứa payload PostgreSQL thành công, Web Security Academy hiển thị trạng thái Solved và thông báo:

Kết luận: Qua quá trình thực hành, chúng ta đã xác định được rằng ứng dụng có lỗ hổng Blind SQL Injection tại cookie TrackingId. Do ứng dụng không hiển thị dữ liệu trực tiếp và không trả về lỗi SQL, chúng ta sử dụng kỹ thuật Time-Based SQL Injection để kiểm tra. Payload thành công là:

1

'||pg_sleep(10)--

Khi payload được thực thi, server phản hồi chậm rõ rệt, chứng minh rằng câu lệnh SQL chèn vào đã được database xử lý. Đây là bằng chứng cho thấy ứng dụng chưa sử dụng cơ chế truy vấn an toàn như prepared statements hoặc parameterized queries.