SQL Injection là gì? Cách thức tấn công và cách phòng chống

SQL Injection là một trong những lỗ hổng bảo mật phổ biến trong các ứng dụng web có kết nối cơ sở dữ liệu. Lỗ hổng này xuất hiện khi dữ liệu do người dùng cung cấp được đưa trực tiếp vào câu lệnh SQL mà không được xử lý và tham số hóa đúng cách. Khi đó, kẻ tấn công có thể khiến hệ thống hiểu một phần dữ liệu đầu vào như câu lệnh SQL, từ đó thay đổi logic truy vấn ban đầu. Tùy vào mức độ kiểm soát và quyền của tài khoản cơ sở dữ liệu, SQL Injection có thể dẫn đến việc đọc trái phép dữ liệu, thay đổi hoặc xóa dữ liệu, vượt qua cơ chế xác thực và trong một số trường hợp nghiêm trọng có thể mở rộng ảnh hưởng sang hệ thống máy chủ. OWASP hiện xếp Injection ở vị trí A05 trong OWASP Top 10:2025, trong đó SQL Injection được xem là một dạng injection có tần suất thấp hơn một số loại khác nhưng có mức độ tác động cao.

SQL Injection là gì?

SQL Injection, thường viết tắt là SQLi, là kỹ thuật khai thác lỗ hổng trong quá trình ứng dụng xây dựng và thực thi truy vấn SQL. Về bản chất, vấn đề không nằm ở bản thân SQL mà nằm ở việc ứng dụng không tách biệt dữ liệu đầu vào với câu lệnh SQL.

Một ứng dụng web thông thường có thể nhận dữ liệu từ form đăng nhập, thanh tìm kiếm, URL, cookie, API hoặc các tham số gửi từ trình duyệt. Ứng dụng sau đó sử dụng dữ liệu này để truy vấn cơ sở dữ liệu. Nếu lập trình viên xây dựng truy vấn bằng cách nối trực tiếp chuỗi, dữ liệu do người dùng kiểm soát có thể tác động đến cấu trúc của câu lệnh SQL.

Ví dụ về mặt nguyên lý, một ứng dụng có thể tạo truy vấn theo dạng:

SELECT * FROM users WHERE username = '[user_input]';

Nếu user_input chỉ được xem như dữ liệu, truy vấn hoạt động bình thường. Nhưng nếu ứng dụng ghép chuỗi thiếu an toàn, đầu vào của người dùng có thể làm thay đổi cấu trúc câu lệnh. Đây chính là điểm mà SQL Injection có thể xảy ra.

Theo OWASP, nguyên nhân phổ biến của SQL Injection là việc xây dựng dynamic SQL query bằng cách nối chuỗi với dữ liệu không đáng tin cậy từ người dùng. Giải pháp cốt lõi là không để dữ liệu đầu vào có khả năng thay đổi cấu trúc của câu lệnh SQL.

SQL Injection hoạt động như thế nào?

Để hiểu SQL Injection, cần hình dung mối quan hệ giữa ứng dụng – câu lệnh SQL – cơ sở dữ liệu. Người dùng gửi một yêu cầu đến ứng dụng, chẳng hạn đăng nhập hoặc tìm kiếm sản phẩm. Ứng dụng lấy dữ liệu từ request và tạo truy vấn SQL. Truy vấn này được gửi tới hệ quản trị cơ sở dữ liệu như MySQL, PostgreSQL, Microsoft SQL Server hoặc Oracle. Database xử lý câu lệnh và trả kết quả về cho ứng dụng.

Vấn đề xảy ra khi ứng dụng coi dữ liệu không đáng tin cậy như một phần của câu lệnh. Thay vì database chỉ nhận được “giá trị cần tìm”, nó có thể nhận một chuỗi đã làm thay đổi logic truy vấn.

Có thể hình dung đơn giản:

Dữ liệu người dùng → Ứng dụng → Ghép vào SQL không an toàn → Database hiểu cả dữ liệu như SQL → Kết quả ngoài dự kiến

Trong một ứng dụng được thiết kế an toàn, quy trình phải được tách biệt:

Dữ liệu người dùng → Parameterized Query → Database xử lý dữ liệu như giá trị → Không thay đổi cấu trúc SQL

Đây cũng là lý do OWASP khuyến nghị sử dụng Prepared Statements/Parameterized Queries, bởi phương pháp này giúp database phân biệt phần nào là câu lệnh SQL và phần nào là dữ liệu.

Các dạng SQL Injection phổ biến

SQL Injection không chỉ có một cách khai thác. Dựa trên cách kẻ tấn công đưa dữ liệu ra khỏi hệ thống, OWASP phân loại SQL Injection thành ba nhóm chính: In-band SQL Injection, Blind/Inferential SQL Injection và Out-of-band SQL Injection.

In-band SQL Injection

Đây là dạng dễ quan sát nhất vì dữ liệu được khai thác và kết quả được trả về thông qua cùng một kênh. Ví dụ, một lỗ hổng trên trang tìm kiếm có thể khiến ứng dụng trả về dữ liệu cơ sở dữ liệu ngoài phạm vi dự kiến.

Dạng này thường được chia thành các kỹ thuật như Union-based SQL Injection hoặc Error-based SQL Injection. Với Error-based SQL Injection, thông báo lỗi từ database vô tình cung cấp thông tin về cấu trúc truy vấn, bảng hoặc hệ quản trị cơ sở dữ liệu. Với Union-based SQL Injection, kẻ tấn công tìm cách khiến kết quả của một truy vấn được kết hợp với truy vấn khác.

Blind SQL Injection

Blind SQL Injection nguy hiểm ở chỗ ứng dụng không trực tiếp hiển thị dữ liệu database cho người tấn công. Thay vào đó, kẻ tấn công quan sát sự khác biệt trong phản hồi của ứng dụng để suy luận thông tin.

Chẳng hạn, hai request có thể tạo ra phản hồi khác nhau về nội dung, trạng thái HTTP hoặc thời gian phản hồi. Từ những khác biệt này, attacker có thể từng bước suy luận thông tin trong database.

Blind SQL Injection thường được chia thành Boolean-based và Time-based SQL Injection. Đây cũng là lý do một ứng dụng không hiển thị lỗi SQL ra màn hình vẫn có thể tồn tại lỗ hổng.

Out-of-band SQL Injection

Out-of-band SQL Injection sử dụng một kênh khác để truyền dữ liệu hoặc nhận phản hồi khi kênh phản hồi trực tiếp không phù hợp. Dạng này phụ thuộc nhiều vào tính năng của hệ quản trị cơ sở dữ liệu và cấu hình môi trường.

Điểm quan trọng là không nên đánh giá mức độ an toàn của ứng dụng chỉ dựa trên việc “website không hiển thị lỗi SQL”. Một ứng dụng vẫn có thể tồn tại SQL Injection ngay cả khi phản hồi trực tiếp không chứa dữ liệu database.

SQL Injection có thể gây ra những hậu quả gì?

Mức độ ảnh hưởng của SQL Injection phụ thuộc vào thiết kế ứng dụng, quyền của tài khoản database, loại hệ quản trị cơ sở dữ liệu và các lớp bảo vệ bổ sung. Tuy nhiên, hậu quả có thể bắt đầu từ việc đọc dữ liệu trái phép và mở rộng đến thay đổi, xóa dữ liệu hoặc thực hiện các thao tác quản trị.

Nếu database chứa thông tin khách hàng, tài khoản, email, số điện thoại, thông tin đơn hàng hoặc dữ liệu nghiệp vụ, một lỗ hổng SQL Injection có thể trở thành điểm khởi đầu cho sự cố rò rỉ dữ liệu. Trong những hệ thống có quyền database được cấp quá rộng, tác động có thể nghiêm trọng hơn.

OWASP lưu ý rằng SQL Injection có thể cho phép attacker đọc dữ liệu, sửa hoặc xóa dữ liệu, thực hiện một số thao tác quản trị trên DBMS và trong những điều kiện nhất định có thể tác động đến hệ thống file hoặc hệ điều hành.

Vì vậy, SQL Injection không đơn thuần là vấn đề “website bị lỗi truy vấn”. Đây là vấn đề kiểm soát ranh giới tin cậy giữa ứng dụng và dữ liệu, có thể ảnh hưởng trực tiếp đến tính bảo mật, toàn vẹn và khả dụng của hệ thống.

Vì sao SQL Injection vẫn là vấn đề bảo mật cần quan tâm?

SQL Injection là một kỹ thuật đã xuất hiện từ lâu nhưng vẫn có ý nghĩa trong bảo mật ứng dụng hiện đại. Nguyên nhân nằm ở việc các hệ thống cũ, code legacy, API và những đoạn xử lý dữ liệu được phát triển thiếu nhất quán vẫn có thể tồn tại truy vấn động không an toàn.

Trong OWASP Top 10:2025, Injection nằm ở nhóm A05:2025, bao gồm SQL Injection cùng nhiều dạng injection khác. OWASP cho biết Injection là một trong những nhóm được kiểm thử nhiều nhất và SQL Injection thuộc nhóm có tác động cao.

Đáng chú ý, việc sử dụng framework hoặc ORM cũng không đồng nghĩa với việc ứng dụng tự động miễn nhiễm SQL Injection. Nếu lập trình viên sử dụng ORM nhưng vẫn tạo truy vấn động không an toàn hoặc đưa dữ liệu không đáng tin cậy vào những vị trí không được tham số hóa, lỗ hổng vẫn có thể xuất hiện.

Cách phòng chống SQL Injection hiệu quả

1. Sử dụng Prepared Statements và Parameterized Queries

Đây là biện pháp quan trọng nhất. Thay vì nối chuỗi để tạo câu SQL, lập trình viên cần định nghĩa câu truy vấn và truyền dữ liệu thông qua tham số.

Ví dụ về nguyên tắc:

SELECT * FROM users WHERE username = ?;

Giá trị username được truyền vào như một parameter thay vì được ghép trực tiếp vào câu SQL. Khi đó, database có thể phân biệt câu lệnh và dữ liệu, giảm khả năng dữ liệu đầu vào thay đổi cấu trúc truy vấn.

OWASP xác định Prepared Statements/Parameterized Queries là phương pháp phòng chống SQL Injection được ưu tiên.

2. Kiểm tra và xác thực dữ liệu đầu vào

Input validation vẫn cần thiết, đặc biệt với những trường dữ liệu có định dạng rõ ràng như ID, số điện thoại, mã sản phẩm hoặc tham số phân trang. Có thể sử dụng allowlist validation, nghĩa là chỉ chấp nhận những giá trị phù hợp với tập giá trị hoặc định dạng được xác định trước.

Tuy nhiên, validation không nên được xem là lớp phòng thủ duy nhất. OWASP nhấn mạnh rằng validation không thể thay thế hoàn toàn parameterized queries vì nhiều trường dữ liệu hợp lệ vẫn có thể chứa ký tự đặc biệt.

3. Áp dụng nguyên tắc Least Privilege

Tài khoản database mà ứng dụng sử dụng chỉ nên có những quyền cần thiết để thực hiện chức năng của ứng dụng. Một ứng dụng chỉ cần đọc dữ liệu không nên sử dụng tài khoản có quyền quản trị database.

Đây là lớp phòng thủ quan trọng bởi ngay cả khi SQL Injection xảy ra, quyền hạn bị giới hạn sẽ giúp giảm phạm vi thiệt hại. OWASP khuyến nghị không cấp quyền DBA hoặc administrator cho tài khoản ứng dụng nếu không thực sự cần thiết.

4. Không hiển thị lỗi database trực tiếp cho người dùng

Thông báo lỗi SQL có thể vô tình tiết lộ tên bảng, cột, cấu trúc truy vấn hoặc loại database đang sử dụng. Ứng dụng nên ghi log chi tiết ở phía server nhưng trả về thông báo lỗi chung cho người dùng.

Điều này không loại bỏ SQL Injection nhưng giúp hạn chế thông tin mà attacker có thể thu thập trong quá trình dò tìm lỗ hổng.

5. Kiểm thử bảo mật trong vòng đời phát triển phần mềm

SQL Injection cần được kiểm tra ngay từ giai đoạn phát triển thay vì chỉ kiểm tra sau khi website đã đưa vào production. Code review có thể tìm kiếm các đoạn xây dựng SQL bằng string concatenation; SAST có thể phân tích source code; DAST có thể kiểm tra ứng dụng đang chạy; còn kiểm thử fuzzing giúp đánh giá cách hệ thống xử lý nhiều loại input khác nhau.

OWASP Top 10:2025 cũng đề cập việc kết hợp code review, kiểm thử tự động và các công cụ SAST, DAST, IAST trong CI/CD để phát hiện injection sớm hơn.

6. Bảo vệ database ở tầng hạ tầng

Phòng chống SQL Injection không chỉ là trách nhiệm của lập trình viên. Database cũng cần được bảo vệ bằng phân quyền, phân đoạn mạng, firewall và hạn chế các host có khả năng kết nối trực tiếp tới database. OWASP khuyến nghị backend database chỉ nên cho phép kết nối từ những nguồn thực sự cần thiết.

SQL Injection khác gì XSS?

SQL Injection và Cross-Site Scripting (XSS) đều thuộc nhóm Injection nhưng mục tiêu và cơ chế khác nhau. SQL Injection nhắm vào trình thông dịch SQL/database, trong khi XSS chủ yếu nhắm tới cách trình duyệt xử lý nội dung không đáng tin cậy. SQL Injection có thể tác động đến dữ liệu và logic truy vấn của database, còn XSS có thể khiến trình duyệt thực thi nội dung script ngoài ý muốn.

Điểm chung quan trọng giữa hai lỗ hổng là vấn đề dữ liệu không đáng tin cậy được đưa vào một interpreter hoặc ngữ cảnh thực thi mà không được xử lý đúng cách. Đây cũng là lý do OWASP đưa nhiều loại injection vào cùng một nhóm A05:2025.

Doanh nghiệp cần làm gì để giảm nguy cơ SQL Injection?

Một chiến lược hiệu quả không nên chỉ dựa vào một công cụ hoặc một bộ lọc. Doanh nghiệp cần xây dựng nhiều lớp bảo vệ từ secure coding, parameterized queries, input validation, phân quyền database, quản lý lỗi, logging, kiểm thử bảo mật đến giám sát hệ thống.

Đặc biệt, cần rà soát các ứng dụng cũ và những API có khả năng nhận dữ liệu trực tiếp từ Internet. Những đoạn code sử dụng dynamic SQL, truy vấn được xây dựng bằng cách nối chuỗi hoặc stored procedure có chứa dynamic SQL cần được đánh giá kỹ. OWASP cũng lưu ý rằng stored procedure không mặc nhiên an toàn nếu bên trong vẫn xây dựng SQL động hoặc thực thi dữ liệu không đáng tin cậy.

Kết luận

SQL Injection là gì? Đây là lỗ hổng xảy ra khi dữ liệu không đáng tin cậy có thể tác động đến cấu trúc và logic của câu lệnh SQL mà ứng dụng gửi tới database. Nếu bị khai thác, SQL Injection có thể dẫn tới truy cập dữ liệu trái phép, thay đổi hoặc xóa dữ liệu và trong một số điều kiện có thể mở rộng phạm vi ảnh hưởng sang các thành phần khác của hệ thống.

Điểm quan trọng nhất khi phòng chống SQL Injection là không để dữ liệu và câu lệnh bị trộn lẫn. Doanh nghiệp và lập trình viên nên ưu tiên Prepared Statements/Parameterized Queries, kết hợp allowlist validation, nguyên tắc Least Privilege, kiểm soát lỗi, kiểm thử bảo mật và bảo vệ database ở tầng hạ tầng. Đây không chỉ là biện pháp xử lý một lỗ hổng cụ thể mà còn là nền tảng của Secure Software Development.