Giải phẫu một cuộc tấn công SQL Injection
Để có thể tiến hành SQL Injection bắt buộc phải có hai điều kiện cần thiết tồn tại: một lược đồ quan hệ cơ sở dữ liệu dùng SQL và người dùng có thể điều chỉnh đầu vào một cách trực tiếp thông qua sử dụng các truy vấn SQL.
Trong ví dụ bên dưới đây, ta giả định rằng kẻ tấn công đã thành công khi lấy được dữ liệu rò rỉ từ cơ sở dữ liệu thông qua các bước khai thác với lỗ hỗng SQL Injection hiện có trong ứng dụng web. Bằng cách cung cấp các câu lệnh SQL đầu vào không đúng nguyên tắc sẵn có, chẳng hạn nhập vào một chuỗi trong khi truy vấn SQL lại là kiểu số nguyên, hoặc cố tình chèn vào đó một lỗi cú pháp để truy vấn ngược lên cơ sở dữ liệu của máy chủ nhằm ép nó trả về lỗi để tận dụng khai thác. Nên nhớ, các lỗi này cực kỳ hữu dụng và có ích trong quá trình các nhà phát triển sản phẩm tiến hành thẩm định và thử nghiệm, nhưng nếu nó xuất hiện trong quá trình website đã được đưa vào vận hành rồi, thì nó hoàn toàn có thể phản tác dụng khi từ đó, kẻ tấn công sẽ triệt để nhắm vào mục tiêu này và khai thác thông tin của ta từ nó.
Sở dĩ kẻ tấn công cố gắng “tiêm” vào các truy vấn để tìm lỗi, vì các lỗi SQL này thường cung cấp rất nhiều thông tin trỏ đến nơi yếu điểm giúp kẻ xấu nắm giữ được thông tin về cấu trúc của cơ sở dữ liệu, và trong một số trường hợp, thậm chí nó sẽ liệt kê ra toàn bộ thông tin của hệ cơ sở dữ liệu kèm theo lỗi trên màn hình cho ta thấy. Kỹ thuật này thường được gọi với cái tên error-based SQL injection. Do nguy hiểm là vậy, nhiệm vụ của các nhà quản trị và phát triển ứng dụng web phải tìm cách vô hiệu hóa nó đi khi đã đưa website vào vận hành, hoặc đẩy những luồng truy vấn trái phép như ta kể trên vào khu vực hạn chế hoặc hay hơn, ta sẽ chặn luồng truy vấn xuất phát từ vị trí đó.
Một kỹ thuật phổ thông khác để lấy thông tin dữ liệu khác trong kiểu tấn công SQL Injection này đó là lợi dụng vào toán tử UNION của SQL. Nếu sử dụng linh hoạt, nó sẽ cho phép kẻ tấn công kết hợp kết quả trả về của hai hay nhiều câu lệnh SELECT vào trong một kết quả duy nhất. Nỗ lực của kỹ thuật này nhằm bắt buộc ứng dụng phải trả về dữ liệu ngay trong chính các gói HTTP phản hồi – còn được biết với cái tên union-based SQL injection.
Một ví dụ nhỏ sau đây là minh chứng cho kiểu tấn công trên. Để thực hiện minh họa, ta có thể thực nghiệm ngay ở địa chỉ testphp.vulnweb.com – một trang web mẫu được Acunetix vận hành cho người dùng sử dụng làm LAB.
Ta thấy rằng, đoạn HTTP request này hoàn toàn ổn và do một người dùng bình thường gửi đi.
GET http://testphp.vulnweb.com/artists.php?artist=1 HTTP/1.1
Host: testphp.vulnweb.com
Mặc dù đoạn request phía trên là bình thường, nhưng chính tham số ở chỗ artist trong kết quả trả về mới chính là điểm yếu để dựa vào tấn công SQL Injection.
Đoạn SQL Injection thực hiện chèn payload phía dưới đây sẽ hiệu chỉnh câu truy vấn để nhằm tìm kiếm một bản ghi hoàn toàn không tồn tại bằng cách điều chỉnh giá trị chuỗi trong câu lệnh sang -1 (hoặc nó có thể là một giá trị khác bất kỳ không tồn tại trong cơ sở dữ liệu, tuy nhiên theo suy luận, một ID trong cơ sở dữ liệu bao giờ cũng ít có khả năng là một số âm).
Lúc này, kẻ tấn công sử dụng thêm toán tử UNION để kết nối câu truy vấn độc hại kèm với truy vấn gốc ban đầu và truy xuất yêu cầu lên ứng dụng web. Như vậy, ngoài kết quả gốc ban đầu, ta còn được thêm thông tin về các dữ liệu nhạy cảm nguy hiểm nhưng có lợi cho kẻ xấu như lúc này, hắn sẽ lấy được giá trị của các cột từ các bảng khác.
GET http://testphp.vulnweb.com/artists.php?artist=-1 UNION SELECT 1, 2, 3 HTTP/1.1
Host: testphp.vulnweb.com
Ví dụ trên đây đã chứng minh rằng các truy vấn với cơ sở dữ liệu có thể bị hiệu chỉnh để trả về dữ liệu mà kẻ tấn công muốn nhắm đến. Còn với ví dụ sau cuối này, ta thấy được một ví dụ trực quan hơn về chèn payload có thể lấy được thông tin nhạy cảm từ chính website bị lỗi bằng cách truy vấn như thế nào.
GET http://testphp.vulnweb.com/artists.php?artist=-1 UNION SELECT 1,pass,cc FROM users WHERE uname=’test’ HTTP/1.1
Host: testphp.vulnweb.com
Qua những gì ta thấy được bằng việc thực hiện pentest trên đây, dĩ nhiên là một ví dụ nhỏ thôi, nhưng những gì có thể thực hiện được bằng SQL Injection quả thật cực kỳ hữu dụng trong việc khai thác. Chỉ bằng nỗ lực tìm ra giá trị id bị lỗi, và lỗi ở giá trị nào, sau đó kẻ tấn công liên tục thử nghiệm trên chính lỗ hổng đó. Đến khi có kết quả trả về trên màn hình, đến đây nạn nhân gần như đã không còn có thể chống đỡ được.
Nếu đi sâu hơn nữa, kẻ tấn công có thể lấy được toàn bộ thông tin, nhưng cái quan trọng và đáng để khai thác nhất chính là thông tin về user quản trị. Người quản trị nếu không cẩn thận có thể bị xem hết dữ liệu quan trọng. Một cách chống chọi cuối cùng ở chỗ này – dẫu kẻ địch đã tiến rất sâu vào thành – đó là hãy băm (hash) toàn bộ dữ liệu quan trọng chứa trong cơ sở dữ liệu của mình. Việc hash mật khẩu sẽ làm chậm đi bước tiến đến khâu cuối cùng của kẻ xấu, nếu như mật khẩu của bạn tốt và mã băm đó chưa từng nằm trong các danh sách decrypt hash của các site hỗ trợ việc hash trên mạng.
VÕ TÌNH THƯƠNG
votinhthuong9@gmail.com
