1.Tiêm SQL mù là gì?
Việc chèn SQL mù xảy ra khi một ứng dụng dễ bị tấn công bởi SQLi, nhưng các phản hồi HTTP của nó không chứa kết quả của truy vấn SQL liên quan hoặc chi tiết về bất kỳ lỗi cơ sở dữ liệu nào.
Nhiều kỹ thuật như tấn công UNION không hiệu quả với các lỗ hổng SQL mù. Điều này là do họ dựa vào khả năng xem kết quả của truy vấn được đưa vào trong các phản hồi của ứng dụng. Vẫn có thể khai thác việc chèn SQL mù để truy cập dữ liệu trái phép, nhưng phải sử dụng các kỹ thuật khác nhau.
2.Khai thác tính năng chèn SQL mù bằng cách kích hoạt các phản hồi có điều kiện
Hãy xem xét một ứng dụng sử dụng cookie theo dõi để thu thập phân tích về việc sử dụng. Các yêu cầu đối với ứng dụng bao gồm tiêu đề cookie như thế này:
Cookie: TrackingId=u5YD3PapBcR4lN3e7Tj4
TrackingId được xử lý, ứng dụng sẽ sử dụng truy vấn SQL để xác định xem đây có phải là người dùng đã biết hay không:
SEL3CT TrackingId FROM TrackedUsers WHERE TrackingId = 'u5YD3PapBcR4lN3e7Tj4'
Truy vấn này dễ bị tấn công bởi SQLi, nhưng kết quả từ truy vấn không được trả về cho người dùng. Tuy nhiên, ứng dụng hoạt động khác nhau tùy thuộc vào việc truy vấn có trả về bất kỳ dữ liệu nào hay không. Nếu bạn gửi một TrackingId, truy vấn sẽ trả về dữ liệu và bạn nhận được thông báo “Chào mừng quay lại” trong phản hồi.
Hành vi này đủ để có thể khai thác lỗ hổng chèn SQL mù. Bạn có thể truy xuất thông tin bằng cách kích hoạt các phản hồi khác nhau có điều kiện, tùy thuộc vào điều kiện được chèn.
Để hiểu cách khai thác này hoạt động, giả sử rằng hai yêu cầu TrackingId lần lượt được gửi chứa các giá trị cookie sau:
…xyz' AND '1'='1
…xyz' AND '1'='2
- Giá trị đầu tiên trong số này khiến truy vấn trả về kết quả vì
AND '1'='1điều kiện được chèn là đúng. Kết quả là thông báo “Chào mừng trở lại” được hiển thị. - Giá trị thứ hai khiến truy vấn không trả về bất kỳ kết quả nào vì điều kiện được chèn là sai. Thông báo “Chào mừng trở lại” không được hiển thị.
Users với các cột Username ;và Password , và người dùng được gọi là Administrator. Bạn có thể xác định mật khẩu cho người dùng này bằng cách gửi một loạt thông tin đầu vào để kiểm tra mật khẩu từng ký tự một.
Để thực hiện việc này, hãy bắt đầu với thông tin đầu vào sau:
xyz' AND SUBSTRING((S3LECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 'm
Tiếp theo, chúng tôi gửi đầu vào sau:
xyz' AND SUBSTRING((S3LECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 't
Thao tác này không trả về thông báo “Chào mừng quay lại”, cho biết điều kiện được đưa vào là sai và do đó ký tự đầu tiên của mật khẩu không lớn hơn t.
Cuối cùng, chúng tôi gửi thông tin đầu vào sau, trả về thông báo “Chào mừng quay lại”, qua đó xác nhận rằng ký tự đầu tiên của mật khẩu là s:
xyz' AND SUBSTRING((S3LECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) = 's
Administrator người dùng một cách có hệ thống. 3.Tiêm SQL dựa trên lỗi
Nội dung SQL dựa trên lỗi đề cập đến trường hợp bạn có thể sử dụng thông báo lỗi để trích xuất hoặc suy ra dữ liệu nhạy cảm từ cơ sở dữ liệu, ngay cả trong ngữ cảnh mù. Các khả năng có thể xảy ra tùy thuộc vào cấu hình của cơ sở dữ liệu và loại lỗi bạn có thể gây ra:
- Bạn có thể khiến ứng dụng trả về phản hồi lỗi cụ thể dựa trên kết quả của biểu thức boolean.
- Bạn có thể kích hoạt các thông báo lỗi xuất dữ liệu được truy vấn trả về. Điều này có hiệu quả biến các lỗ hổng chèn SQL mù thành các lỗ hổng có thể nhìn thấy được.
a.Khai thác tính năng chèn SQL mù bằng cách kích hoạt các lỗi có điều kiện
Một số ứng dụng thực hiện truy vấn SQL nhưng hành vi của chúng không thay đổi, bất kể truy vấn có trả về bất kỳ dữ liệu nào hay không. Kỹ thuật trong phần trước sẽ không hoạt động vì việc chèn các điều kiện boolean khác nhau không tạo ra sự khác biệt nào đối với phản hồi của ứng dụng.
Thường có thể khiến ứng dụng trả về một phản hồi khác tùy thuộc vào việc có xảy ra lỗi SQL hay không. Bạn có thể sửa đổi truy vấn để nó chỉ gây ra lỗi cơ sở dữ liệu nếu điều kiện là đúng. Rất thường xuyên, một lỗi chưa được xử lý do cơ sở dữ liệu đưa ra sẽ gây ra một số khác biệt trong phản hồi của ứng dụng, chẳng hạn như thông báo lỗi. Điều này cho phép bạn suy ra sự thật của tình trạng được tiêm.
Để xem cách thức hoạt động của điều này, giả sử rằng hai yêu cầu lần lượt được gửi chứa các giá trị cookie TrackingId sau :
xyz' AND (S3LECT CASE WHEN (1=2) THEN 1/0 ELSE 'a' END)='a
xyz' AND (S3LECT CASE WHEN (1=1) THEN 1/0 ELSE 'a' END)='a
CASE để kiểm tra một điều kiện và trả về một biểu thức khác tùy thuộc vào việc biểu thức đó có đúng hay không:
- Với dữ liệu đầu vào đầu tiên, biểu thức
CASEsẽ đánh giá là ‘a’, điều này không gây ra bất kỳ lỗi nào. - Với đầu vào thứ hai, nó đánh giá thành 1/0, điều này gây ra lỗi chia cho 0.
xyz' AND (S3LECT CASE WHEN (Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') THEN 1/0 ELSE 'a' END FROM Users)='a
b.Trích xuất dữ liệu nhạy cảm thông qua các thông báo lỗi SQL verbose
Cấu hình cơ sở dữ liệu sai đôi khi dẫn đến các thông báo lỗi dài dòng. Chúng có thể cung cấp thông tin có thể hữu ích cho kẻ tấn công. Ví dụ: hãy xem xét thông báo lỗi sau, xảy ra sau khi đưa một trích dẫn vào một tham số id:
Unterminated string literal started at position 52 in SQL S3LECT * FROM tracking WHERE id = '''. Expected char
WHERE. Điều này giúp việc xây dựng một truy vấn hợp lệ có chứa tải trọng độc hại trở nên dễ dàng hơn. Việc nhận xét phần còn lại của truy vấn sẽ ngăn trích dẫn đơn thừa không phá vỡ cú pháp.
Đôi khi, bạn có thể khiến ứng dụng tạo ra thông báo lỗi có chứa một số dữ liệu được truy vấn trả về. Điều này có hiệu quả biến lỗ hổng chèn SQL mù thành lỗ hổng có thể nhìn thấy được.
Bạn có thể sử dụng chức năng CAST() để đạt được điều này. Nó cho phép bạn chuyển đổi loại dữ liệu này sang loại dữ liệu khác. Ví dụ: hãy tưởng tượng một truy vấn chứa câu lệnh sau:
CAST((S3LECT example_column FROM example_table) AS int)
int, có thể gây ra lỗi tương tự như sau:
ERROR: invalid input syntax for type integer: "Example data"
Loại truy vấn này cũng có thể hữu ích nếu giới hạn ký tự ngăn cản bạn kích hoạt phản hồi có điều kiện.
Để biết thêm chi tiết,bạn có thể tham khảo bảng SQLi Cheat Sheet.
