Chào bạn, đây là tôi, bạn là ai vậy? Sao bạn lại đăng nhập được vào hệ thống của tôi mà không có mật khẩu??? Ảo thật đấy!!!
Chào tôi, đây là bạn, bạn dùng SQL Injection 
Ngày hôm nay, chúng ta cùng tìm hiểu về kỹ thuật này:
I. Định Nghĩa & Đặc Điểm
SQL Injection là một kỹ thuật tấn công phổ biến trong lĩnh vực bảo mật ứng dụng web. Khi không kiểm tra và xử lý đúng các dữ liệu người dùng nhập vào, kẻ tấn công có thể chèn các câu lệnh SQL độc hại vào truy vấn SQL của ứng dụng, từ đó lợi dụng để thực hiện các hoạt động không được phép như đọc, sửa, xóa dữ liệu trong cơ sở dữ liệu.
Dưới đây là một số phương thức tấn công SQL Injection phổ biến:
1. Tấn công SQL Injection dựa trên đoạn mã chèn vào trường dữ liệu:
Kẻ tấn công chèn các đoạn mã SQL độc hại vào trường dữ liệu như tên người dùng, mật khẩu hoặc các thông tin khác. Ví dụ:
- Đoạn mã SQL chèn vào trường tên người dùng: ' OR 1=1; --
- Đoạn mã SQL chèn vào trường mật khẩu: ' OR 'a'='a' --
Giả sử chúng ta có trang web đăng nhập với hai trường nhập liệu: "username" và "password". Mục tiêu của chúng ta là xâm nhập vào hệ thống bằng cách lợi dụng lỗ hổng SQL Injection.
Trong trường "username" hoặc "password", chúng ta nhập vào đoạn mã sau: ' OR '1'='1'; --
Khi ứng dụng không xử lý đúng dữ liệu này, câu truy vấn SQL sẽ trở thành:
SELECT * FROM users WHERE username = '' OR '1'='1'; --' AND password = ''
- Kết quả là câu truy vấn trả về tất cả bản ghi trong bảng "users", cho phép đăng nhập mà không cần biết tên người dùng hoặc mật khẩu đúng.
2. Tấn công SQL Injection dựa trên câu truy vấn ghép chuỗi: Kẻ tấn công ghép chuỗi các đoạn mã SQL độc hại vào câu truy vấn SQL. Ví dụ:
- Đoạn mã SQL chèn vào câu truy vấn SELECT: ' OR '1'='1'; DROP TABLE users; --
- Đoạn mã SQL chèn vào câu truy vấn INSERT: ' UNION SELECT username, password FROM users; --
Khi ứng dụng không kiểm tra và xử lý đúng các giá trị ghép chuỗi này, câu truy vấn SQL sẽ được thực thi không đúng và có thể gây ra hậu quả nghiêm trọng.
Giả sử chúng ta có một trang web hiển thị thông tin sản phẩm dựa trên một tham số truy vấn "product_id" được truyền vào URL.
Với sự kiểm soát yếu của ứng dụng, kẻ tấn công có thể thực hiện SQL Injection để lấy thông tin từ các bảng khác nhau trong cơ sở dữ liệu.
Ví dụ, bằng cách chèn UNION SELECT, kẻ tấn công có thể lấy thông tin từ bảng "users" và bảng "credit_cards" cùng lúc.
URL BỊ SỬA: http://example.com/product.php?product_id=1 UNION SELECT username, credit_card_number FROM users, credit_cards
Kết quả câu truy vấn trở thành:
SELECT product_name, product_description FROM products WHERE product_id = 1
UNION SELECT username, credit_card_number FROM users, credit_cards
Kết quả trả về sẽ là một kết hợp của thông tin sản phẩm từ bảng "products" và thông tin người dùng, số thẻ tín dụng từ bảng "users" và "credit_cards". Điều này có thể gây lộ thông tin nhạy cảm cho kẻ tấn công.
Theo mặc định, Eloquent ORM của Laravel bảo vệ chống lại SQL injection bằng cách tham số hóa các truy vấn và sử dụng các ràng buộc SQL. Các framework cũng
3. Time-based SQL Injection:
Giả sử ứng dụng có tính năng truy vấn dữ liệu và thời gian phản hồi của truy vấn có thể ảnh hưởng bởi câu lệnh SQL.
Ví dụ:
Người tấn công chèn câu lệnh SQL gây trễ vào trường tìm kiếm. Ví dụ, người tấn công có thể chèn
"apple'; WAITFOR DELAY '0:0:10' --"
để tạo trễ 10 giây trong câu lệnh truy vấn.
Nếu ứng dụng có thời gian phản hồi lâu hơn bình thường, người tấn công có thể suy ra rằng câu lệnh SQL đã được thực thi.
4. Stored Procedure Injection
Stored Procedure Injection là một kỹ thuật tấn công SQL Injection nơi kẻ tấn công chèn các câu lệnh SQL độc hại vào các stored procedure đã tồn tại hoặc tạo mới trong cơ sở dữ liệu. Stored procedure là một khối mã SQL lưu trữ trong cơ sở dữ liệu và có thể được gọi và thực thi từ các ứng dụng hoặc các truy vấn SQL.
Giả sử chúng ta có một stored procedure trong cơ sở dữ liệu có tên là spGetUserDetails để lấy thông tin chi tiết của một người dùng dựa trên ID:
CREATE PROCEDURE sp_GetUserDetails @UserID INT
AS
BEGIN SELECT * FROM Users WHERE ID = @UserID;
END; Hacker có thể chèn một câu lệnh SQL độc hại vào tham số @UserID của stored procedure để lấy thông tin của tất cả các người dùng hoặc thực hiện các hành động không mong muốn, ví dụ:
EXEC sp_GetUserDetails '1; DELETE FROM Users; --'
Trong trường hợp trên, câu lệnh SQL được chèn vào tham số @UserID sẽ được thực thi trong stored procedure, và nó sẽ xóa tất cả các bản ghi trong bảng Users.
II. Cách Phòng Ngừa SQL Injection:
Các framework của các ngôn ngữ lập trình phổ biến đã tích hợp các cơ chế và công cụ để hỗ trợ phòng chống SQL Injection. Tuy nhiên, việc đảm bảo an toàn tuyệt đối và ngăn chặn SQL Injection nhất định KHÔNG CHỦ QUAN và là trách nhiệm của người phát triển ứng dụng.
Các framework cung cấp các cơ chế truy vấn an toàn như ORM, query builder, stored procedures và prepared statements. Sử dụng các cơ chế này giúp tự động xử lý việc truy vấn dữ liệu và tham số hóa, giảm nguy cơ SQL Injection.
Dưới đây là một số cách mà các framework thường sử dụng để chống SQL Injection:
-
Thực hiện truy vấn tham số hóa (Parameterized Queries/Prepared Statements): Các framework cung cấp cách sử dụng truy vấn tham số hóa để tách biệt giữa câu lệnh SQL và dữ liệu đầu vào. Điều này đảm bảo rằng dữ liệu người dùng sẽ không được xem là một phần của câu lệnh SQL, từ đó ngăn chặn SQL Injection.
-
Sử dụng ORM (Object-Relational Mapping): Các framework cung cấp ORM giúp giảm tiếp xúc trực tiếp với SQL bằng cách tạo ra các đối tượng và thực hiện các hoạt động trên đối tượng thay vì trực tiếp tạo câu lệnh SQL. ORM sẽ tự động xử lý việc truy vấn và tham số hóa dữ liệu, giúp ngăn chặn SQL Injection.
-
Hạn chế quyền truy cập cơ sở dữ liệu: Cung cấp quyền truy cập cơ sở dữ liệu cần thiết cho người dùng ứng dụng, đảm bảo rằng các người dùng không có quyền truy cập, thực thi hoặc thay đổi các câu lệnh SQL không cần thiết.
-
Kiểm tra thử bảo mật: Thực hiện kiểm tra thử bảo mật (penetration testing) để xác định và khắc phục các lỗ hổng bảo mật trong ứng dụng và cơ sở dữ liệu. Điều này giúp phát hiện và sửa chữa các lỗi SQL Injection trước khi ứng dụng được triển khai.
Tuy nhiên, việc sử dụng framework không đảm bảo 100% an toàn. Người phát triển ứng dụng vẫn phải tuân thủ các nguyên tắc và quy tắc an toàn lập trình, kiểm tra và xác thực dữ liệu đầu vào, và kiểm tra bảo mật tổng thể của ứng dụng để đảm bảo tránh SQL Injection và các lỗ hổng bảo mật khác.