SQL injection là gì?

Mục lục

1. SQL injection là gì?
2. SQL injection hoạt động như thế nào?
3. Vì sao SQL injection vẫn nguy hiểm vào năm 2026?
4. Các loại SQL injection phổ biến
5. SQL injection gây ra hậu quả gì cho doanh nghiệp?
6. Những chỗ nào trong ứng dụng dễ dính SQL injection?
7. Phòng chống SQL injection: bắt đầu từ truy vấn tham số hoá
8. WAF có chặn được SQL injection không?
9. Kiểm thử an toàn SQL injection thế nào cho đúng?
10. Quy trình vá khi phát hiện lỗ hổng SQL injection
11. Checklist phòng chống SQL injection theo vai trò
12. SQL injection khác XSS và các lỗi injection khác thế nào?
13. Câu hỏi thường gặp

SQL injection là gì?

SQL injection (viết tắt SQLi, còn gọi là tấn công chèn mã SQL) là lỗ hổng bảo mật trong ứng dụng dùng cơ sở dữ liệu quan hệ. Nó xuất hiện khi ứng dụng lấy dữ liệu từ bên ngoài, như ô tìm kiếm, ô đăng nhập hay tham số trên đường dẫn, rồi ghép thẳng vào câu lệnh SQL. Nếu dữ liệu chứa ký tự có ý nghĩa cú pháp, cơ sở dữ liệu có thể hiểu một phần dữ liệu thành lệnh và chạy nó.

MITRE, đơn vị duy trì danh mục điểm yếu phần mềm CWE (Common Weakness Enumeration), đặt cho lỗi này mã CWE-89 với tên “Improper Neutralization of Special Elements used in an SQL Command”. Nghĩa là phần mềm dựng câu lệnh SQL từ dữ liệu bên ngoài mà không vô hiệu hoá các phần tử đặc biệt, nên dữ liệu làm thay đổi ý định của câu lệnh. CWE-89 là nhánh con của CWE-74, nhóm lỗi “injection” nói chung.

Nếu chưa quen với ngôn ngữ truy vấn, bạn có thể đọc trước bài SQL là gì và các câu lệnh cơ bản.

Một ví dụ dễ hình dung

Ví dụ minh hoạ. Nhân viên kho làm theo phiếu in sẵn: “Lấy hồ sơ khách hàng có mã ____”. Một người không điền mã mà viết vào chỗ trống một câu trông như điều kiện bổ sung. Nhân viên không phân biệt phần in sẵn với phần viết tay, nên làm theo cả câu và đưa ra nhiều hồ sơ hơn mức được phép.

Cách sửa không phải dặn nhân viên “đọc kỹ hơn”, mà là đổi quy tắc: phần viết tay luôn là một giá trị cần tra, không bao giờ là một phần mệnh lệnh. Đó là tinh thần của truy vấn tham số hoá.

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

Ở mức nguyên lý, SQL injection xảy ra vì câu lệnh và dữ liệu bị trộn vào cùng một chuỗi. Khi câu lệnh được tạo bằng cách nối “phần đầu câu lệnh” với “giá trị người dùng nhập” và “phần cuối”, cơ sở dữ liệu chỉ nhận một chuỗi hoàn chỉnh. Nó không biết đoạn nào do lập trình viên viết, đoạn nào do người ngoài gửi tới.

Với dữ liệu bình thường, mọi thứ chạy đúng. Nhưng nếu giá trị chứa dấu nháy, dấu chú thích hoặc từ khoá SQL, cấu trúc câu lệnh có thể bị đổi: thêm điều kiện, nối thêm truy vấn, cắt bỏ phần kiểm tra. Từ đó kẻ tấn công có thể đọc dữ liệu không được phép, vượt bước đăng nhập, sửa hoặc xoá bản ghi, và trong cấu hình yếu có thể chiếm quyền cao hơn trên máy chủ.

Với truy vấn tham số hoá, ứng dụng gửi hai thứ tách biệt: mẫu câu lệnh có “chỗ trống” (placeholder) và danh sách giá trị. Cơ sở dữ liệu phân tích mẫu trước, rồi mới gắn giá trị vào như dữ liệu thuần. Dù giá trị chứa ký tự gì, nó không thể trở thành lệnh.

Lỗi không phụ thuộc hệ quản trị: MySQL, PostgreSQL, SQL Server, Oracle hay SQLite đều có thể bị khai thác nếu ứng dụng phía trên ghép chuỗi. Nó cũng không chỉ có ở website mà còn ở ứng dụng di động, phần mềm nội bộ, API cho đối tác, giao diện quản trị của thiết bị. Nền tảng về bảng, bản ghi và hệ quản trị có trong bài cơ sở dữ liệu là gì.

Vì sao SQL injection vẫn nguy hiểm vào năm 2026?

Một trong những bài viết công khai sớm về SQL injection là “NT Web Technology Vulnerabilities” của Jeff Forristal, đăng trên tạp chí Phrack số 54 ngày 25/12/1998. Gần ba thập kỷ sau, lỗi vẫn thuộc nhóm nguy hiểm nhất:

• CWE Top 25 năm 2025 (MITRE cập nhật 15/12/2025): CWE-89 xếp thứ 2 với điểm 28,72, sau Cross-site Scripting. Năm 2024, nó đứng thứ 3.
• OWASP Top 10:2025: nhóm Injection ở vị trí A05 (bản 2021 là hạng 3), gồm 37 CWE và 62.445 CVE. OWASP mô tả SQL injection là lỗi “tần suất thấp, tác động cao”, với hơn 14.000 CVE.
• CISA và FBI (tháng 3/2024) phát hành cảnh báo “Secure by Design Alert: Eliminating SQL Injection Vulnerabilities in Software”, nhắc rằng lỗi này bị coi là “không thể tha thứ” (unforgivable) từ ít nhất năm 2007.

Lý do lỗi còn tồn tại khá đời thường: mã cũ kế thừa qua nhiều đời lập trình viên, trang “tạm” làm nhanh rồi bị quên, phần mềm bên thứ ba ít được rà soát, áp lực ra tính năng khiến bỏ qua rà soát mã.

Ba sự cố cho thấy cái giá phải trả

Sự cố	Điều gì đã xảy ra	Bài học
Heartland Payment Systems (Mỹ, truy tố công bố 17/08/2009)	Theo Bộ Tư pháp Mỹ, nhóm của Albert Gonzalez dùng SQL injection làm bước xâm nhập, bị cáo buộc lấy cắp dữ liệu hơn 130 triệu thẻ.	Lỗi ở ứng dụng web có thể là cửa vào mạng nội bộ; tường lửa mạng không thay được mã an toàn.
TalkTalk (Anh, 10/2015)	Theo cơ quan bảo vệ dữ liệu Anh (ICO), lỗi nằm ở ba trang web cũ kế thừa từ Tiscali; dữ liệu của 156.959 khách bị truy cập, 15.656 khách lộ số tài khoản ngân hàng. Bản vá đã có hơn ba năm rưỡi; hai lần tấn công trước đó không bị phát hiện. Mức phạt: 400.000 bảng Anh.	Gỡ trang cũ, vá đúng hạn, giám sát nhật ký để bắt các lần dò tìm đầu tiên.
MOVEit Transfer (CVE-2023-34362, từ 27/05/2023)	Theo cảnh báo AA23-158A của CISA, nhóm tống tiền CL0P khai thác lỗ hổng SQL injection chưa có bản vá trong phần mềm truyền tệp, cài web shell rồi đánh cắp dữ liệu.	Phần mềm mua ngoài cũng có thể chứa lỗi; cần kiểm kê tài sản và ưu tiên vá hệ thống công khai.

MOVEit là ví dụ của lỗ hổng bị khai thác trước khi có bản vá; khi đó doanh nghiệp chỉ còn trông vào các lớp phòng thủ khác, như giải thích trong bài lỗ hổng zero-day là gì.

Các loại SQL injection phổ biến

Web Security Testing Guide của OWASP (mục WSTG-INPV-05) chia SQL injection theo cách kẻ tấn công nhận kết quả. Với người phòng thủ, cách chia này cho thấy vì sao “trang không hiện lỗi” chưa chắc đã an toàn.

Loại	Đặc điểm	Ý nghĩa với người phòng thủ
In-band (cổ điển)	Kết quả hiện ngay trên trang hoặc trong thông báo lỗi.	Không hiển thị lỗi chi tiết của cơ sở dữ liệu cho người dùng.
Inferential (blind, “mù”)	Không trả dữ liệu trực tiếp; thông tin bị suy ra từ khác biệt nhỏ trong phản hồi hoặc thời gian phản hồi.	Ẩn lỗi là chưa đủ; phải tham số hoá và theo dõi yêu cầu bất thường lặp lại.
Out-of-band	Dữ liệu bị đẩy ra qua kênh khác, thường là kết nối mạng do máy chủ cơ sở dữ liệu tạo ra.	Chặn kết nối ra ngoài không cần thiết, tắt tính năng không dùng.
Second-order (bậc hai)	Dữ liệu độc hại được lưu “bình thường”, rồi bị dùng lại trong truy vấn không an toàn ở chức năng khác.	Không coi dữ liệu đã nằm trong cơ sở dữ liệu là đáng tin; công cụ quét tự động hay bỏ sót loại này.

SQL injection gây ra hậu quả gì cho doanh nghiệp?

Theo bộ ba bảo mật, toàn vẹn, khả dụng (CIA), SQL injection có thể phá vỡ cả ba:

• Bảo mật: lộ thông tin khách hàng, tài khoản, mật khẩu đã băm, dữ liệu tài chính.
• Toàn vẹn: giá, số dư, trạng thái đơn, quyền người dùng bị sửa trái phép. Loại này khó phát hiện vì hệ thống vẫn “chạy bình thường”.
• Khả dụng: dữ liệu bị xoá, bảng bị khoá, dịch vụ phải dừng để điều tra.

Kèm theo là chi phí điều tra, khôi phục, mất lòng tin và rủi ro pháp lý. Tại Việt Nam, cần lưu ý hai luật:

• Luật An ninh mạng số 116/2025/QH15 (thông qua 10/12/2025, hiệu lực 01/07/2026) yêu cầu chủ quản hệ thống thông tin xác định cấp độ, đánh giá rủi ro, giám sát và áp dụng biện pháp bảo vệ theo cấp độ; Nghị định 331/2026/NĐ-CP ngày 19/08/2026 quy định chi tiết việc này.

Nội dung pháp lý mang tính kiến thức, không thay thế tư vấn pháp lý cho trường hợp cụ thể.

Những chỗ nào trong ứng dụng dễ dính SQL injection?

Không chỉ ô đăng nhập hay ô tìm kiếm. Bất kỳ dữ liệu nào đi từ bên ngoài vào câu lệnh SQL đều là nguồn rủi ro:

Nhóm	Cần chú ý
Nguồn đầu vào	Biểu mẫu, tham số đường dẫn, trường ẩn, cookie, tiêu đề HTTP, dữ liệu JSON gửi tới API, tệp CSV hoặc Excel được nhập, dữ liệu từ đối tác
Vị trí trong câu lệnh	Ngoài điều kiện lọc còn có tên cột sắp xếp, chiều sắp xếp, tên bảng. OWASP lưu ý tên bảng, tên cột không thể “thoát ký tự”, nên không được lấy trực tiếp từ người dùng
Stored procedure	An toàn khi chỉ dùng tham số; nguy hiểm nếu bên trong tự dựng SQL động rồi thực thi
ORM, framework	Hàm truy vấn thô hoặc ghép chuỗi trong ngôn ngữ truy vấn của ORM (ví dụ HQL của Hibernate) vẫn có thể bị chèn mã
Hệ thống cũ, bên thứ ba	Trang quản trị cũ, plugin lâu không cập nhật, phần mềm đóng gói mua ngoài

Phòng chống SQL injection: bắt đầu từ truy vấn tham số hoá

SQL Injection Prevention Cheat Sheet của OWASP chia biện pháp thành phòng thủ chính và phòng thủ bổ sung. Cảnh báo của CISA và FBI năm 2024 cũng kết luận: dùng truy vấn tham số hoá với prepared statement để tách mã SQL khỏi dữ liệu, còn “làm sạch” đầu vào là cách mong manh, dễ bị vượt qua.

1. Truy vấn tham số hoá: biện pháp chính

Mọi ngôn ngữ và thư viện kết nối cơ sở dữ liệu phổ biến đều hỗ trợ truy vấn tham số hoá. Nguyên tắc: câu lệnh viết cố định với chỗ trống, giá trị truyền qua tham số riêng, không bao giờ nối vào chuỗi. Để biến nó thành thói quen:

• Đưa “cấm ghép chuỗi vào SQL” vào quy chuẩn viết mã, kèm ví dụ đúng và sai.
• Cấu hình công cụ phân tích mã tĩnh để cảnh báo khi câu lệnh SQL được dựng bằng nối chuỗi.
• Ưu tiên thư viện hoặc ORM tham số hoá mặc định; giới hạn và rà soát kỹ mọi truy vấn thô.

2. Stored procedure và ORM: an toàn có điều kiện

OWASP xếp stored procedure “viết đúng cách” ngang với truy vấn tham số hoá, với điều kiện bên trong không tự dựng SQL động. OWASP Top 10:2025 cũng nhấn mạnh: dùng framework hay ORM không tự động bảo đảm an toàn.

3. Allow-list cho phần không tham số hoá được

Tên bảng, tên cột sắp xếp, chiều tăng giảm không thể đưa vào tham số. OWASP khuyên các giá trị này nên đến từ mã nguồn. Nếu người dùng cần chọn, hãy ánh xạ lựa chọn sang danh sách định sẵn và từ chối mọi thứ khác. Ví dụ người dùng chọn “sắp xếp theo giá”, ứng dụng tra bảng nội bộ để lấy tên cột tương ứng, không dùng nguyên văn chữ gửi lên. Kiểm tra kiểu dữ liệu, độ dài, định dạng vẫn nên làm, nhưng theo OWASP và CWE đó là lớp phòng thủ chiều sâu.

4. Vì sao không nên dựa vào “thoát ký tự” (escaping)

OWASP xếp việc thoát ký tự đặc biệt rồi ghép vào câu lệnh ở mức “rất không khuyến khích” (strongly discouraged): quy tắc khác nhau giữa các hệ quản trị, dễ sót, dễ hỏng khi hệ thống thay đổi. CWE chỉ coi đây là phương án cuối cùng khi buộc phải dùng truy vấn động.

5. Đặc quyền tối thiểu (least privilege)

Nếu một chỗ ghép chuỗi vẫn lọt qua, đặc quyền tối thiểu quyết định thiệt hại lớn đến đâu. Theo OWASP:

• Không cấp quyền quản trị cơ sở dữ liệu (DBA) cho tài khoản ứng dụng; mỗi ứng dụng một tài khoản riêng.
• Hạn chế tối đa quyền tạo, xoá bảng; chức năng chỉ đọc dùng tài khoản chỉ đọc.
• Dùng view để chỉ lộ những cột, dòng cần thiết.
• Không chạy dịch vụ cơ sở dữ liệu bằng tài khoản quản trị hệ điều hành.

6. Xử lý lỗi và ghi nhật ký

CWE-89 khuyến nghị chỉ hiện thông báo lỗi tối thiểu cho người dùng, chi tiết ghi vào nhật ký có bảo vệ. Nhật ký truy vấn lỗi và yêu cầu tăng đột biến từ một nguồn nên được đưa vào hệ thống giám sát để bắt sớm các lần dò tìm, như bài học từ vụ TalkTalk.

WAF có chặn được SQL injection không?

Tường lửa ứng dụng web (WAF, Web Application Firewall) đọc nội dung từng yêu cầu HTTP và có quy tắc nhận diện nhiều mẫu SQL injection phổ biến. WAF chặn được phần lớn lượt dò quét tự động và rất hữu ích để “vá ảo” (virtual patching) trong vài giờ khi lỗ hổng vừa lộ mà mã chưa kịp sửa.

Tuy nhiên, CWE-89 chỉ đánh giá hiệu quả của tường lửa ứng dụng ở mức “trung bình”: WAF có thể bỏ sót biến thể mới, không thấy SQL injection bậc hai và có thể chặn nhầm người dùng thật. Hãy coi WAF là lớp phủ bên ngoài; cách hoạt động và cách chọn có trong bài WAF là gì.

Kiểm thử an toàn SQL injection thế nào cho đúng?

CWE-89 liệt kê các cách phát hiện: phân tích tĩnh, phân tích động, rà soát mã thủ công và rà soát thiết kế. OWASP Top 10:2025 khuyên đưa SAST, DAST và IAST vào chuỗi tích hợp, triển khai liên tục (CI/CD) để bắt lỗi trước khi lên môi trường thật.

Phương pháp	Mạnh ở đâu	Hạn chế
SAST (phân tích tĩnh mã nguồn)	Chạy sớm, chỉ đúng dòng có dữ liệu ngoài chảy vào SQL	Có cảnh báo nhầm; khó với mã bên thứ ba
DAST (quét ứng dụng đang chạy)	Không cần mã nguồn, phản ánh hành vi thật	Dễ sót lỗi bậc hai và luồng nhiều bước
IAST (cảm biến trong ứng dụng khi kiểm thử)	Thấy truy vấn thực sự gửi đi, ít cảnh báo nhầm	Cần tích hợp vào môi trường chạy
Rà soát mã thủ công	Bắt lỗi logic công cụ bỏ qua	Tốn thời gian, phụ thuộc kinh nghiệm
Kiểm thử xâm nhập	Đánh giá mức nghiêm trọng thực tế	Định kỳ, không thay kiểm thử liên tục

Mục WSTG-INPV-05 của OWASP đặt hai mục tiêu cho kiểm thử: xác định điểm có thể chèn SQL, và đánh giá mức nghiêm trọng cùng mức truy cập lỗi có thể mang lại. Phạm vi và cách thuê đơn vị kiểm thử có trong bài pentest là gì.

Quy trình vá khi phát hiện lỗ hổng SQL injection

Lỗ hổng có thể lộ ra từ công cụ quét, báo cáo của nhà nghiên cứu, cảnh báo của nhà cung cấp, hoặc tệ nhất là từ dấu hiệu đã bị khai thác. Quy trình gợi ý:

1. Tiếp nhận: ghi nhận, giao người phụ trách, đánh giá sơ bộ mức nghiêm trọng (hệ thống có công khai ra Internet, có dữ liệu cá nhân hay tài chính không).
2. Xác minh: tái hiện trên bản sao với dữ liệu giả, xác định tài khoản cơ sở dữ liệu liên quan có quyền gì.
3. Giảm thiểu tạm: thêm quy tắc WAF cho đúng đường dẫn, tạm tắt chức năng, thu hẹp quyền; với phần mềm mua ngoài, áp dụng hướng dẫn của nhà sản xuất.
4. Sửa tận gốc: viết lại truy vấn dạng tham số hoá, dùng allow-list cho phần còn lại, hoặc cài bản vá chính thức.
5. Rà cả lớp lỗi: tìm mọi chỗ dựng SQL tương tự trong cùng ứng dụng và thư viện dùng chung. CISA và FBI khuyến nghị loại bỏ cả lớp lỗi, không chỉ một lỗi.
6. Kiểm thử lại: kiểm thử hồi quy, quét lại, nhờ bên báo cáo xác nhận đã đóng nếu lỗi nghiêm trọng.
7. Điều tra nhật ký: lỗ hổng tồn tại bao lâu thì có thể đã bị khai thác bấy lâu; tìm truy vấn bất thường, lượng dữ liệu đọc ra lớn, tài khoản lạ. Có dấu hiệu thì chuyển sang ứng phó sự cố.
8. Báo cáo, cải tiến: họp rút kinh nghiệm và bổ sung quy chuẩn, quy trình.

Checklist phòng chống SQL injection theo vai trò

Cảnh báo của CISA và FBI kêu gọi cả lãnh đạo doanh nghiệp vào cuộc: tổ chức rà soát chính thức mã nguồn, hỏi nhà cung cấp đã làm việc tương tự chưa, và coi an toàn là mục tiêu kinh doanh có đầu tư.

Vai trò	Việc cần làm
Lãnh đạo, quản lý sản phẩm	Danh sách ứng dụng công khai và người chịu trách nhiệm; kế hoạch gỡ trang cũ; điều khoản “không ghép chuỗi SQL, có kiểm thử bảo mật” trong hợp đồng thuê ngoài; ngân sách cho việc sửa lỗi
Đội phát triển	Tham số hoá mọi truy vấn; allow-list cho tên cột, chiều sắp xếp; rà mọi truy vấn thô; tài khoản cơ sở dữ liệu quyền tối thiểu; lỗi chung chung cho người dùng; SAST trong CI/CD
Vận hành, bảo mật	WAF cho ứng dụng công khai; vá hệ quản trị, CMS, plugin theo lịch; giám sát nhật ký; chặn kết nối ra ngoài từ máy chủ cơ sở dữ liệu; sao lưu và diễn tập khôi phục; kiểm thử định kỳ

SQL injection khác XSS và các lỗi injection khác thế nào?

Cả họ lỗi “injection” đều có chung bản chất: dữ liệu không đáng tin được gửi tới một bộ thông dịch và bị hiểu thành lệnh. Khác nhau ở bộ thông dịch bị lừa:

Lỗi	Bộ thông dịch bị lừa	Biện pháp chính
SQL injection (CWE-89)	Cơ sở dữ liệu SQL	Truy vấn tham số hoá
Cross-site Scripting, XSS (CWE-79)	Trình duyệt của người dùng	Mã hoá đầu ra theo ngữ cảnh
NoSQL injection	Cơ sở dữ liệu NoSQL	API truy vấn an toàn, kiểm tra kiểu dữ liệu
OS command injection	Hệ điều hành máy chủ	Tránh gọi lệnh hệ điều hành, truyền tham số riêng

XSS nhắm vào người dùng cuối thay vì cơ sở dữ liệu nên cách phòng chống khác hẳn; xem bài XSS là gì.

Câu hỏi thường gặp

Dùng ORM thì có miễn nhiễm với SQL injection không?

Không hoàn toàn. ORM tham số hoá truy vấn tạo qua hàm chuẩn, nhưng truy vấn thô hoặc ghép chuỗi trong ngôn ngữ truy vấn của ORM vẫn có thể bị chèn mã.

Cơ sở dữ liệu NoSQL có bị SQL injection không?

Không theo nghĩa hẹp, vì NoSQL không dùng cú pháp SQL. Nhưng chúng có thể bị NoSQL injection nếu ứng dụng đưa thẳng dữ liệu người dùng vào cấu trúc truy vấn; OWASP xếp lỗi này chung nhóm A05.

Làm sao biết website của mình có lỗ hổng SQL injection?

Kết hợp rà soát mã, phân tích tĩnh trong quy trình phát triển và quét động trên môi trường thử. Hệ thống quan trọng nên thuê kiểm thử xâm nhập có hợp đồng và phạm vi rõ ràng.

Đã có WAF thì có cần sửa mã không?

Có. WAF chỉ chặn mẫu nó nhận ra và có thể bị vượt qua. Nó phù hợp để giảm thiểu tạm thời trong lúc sửa mã.

Website dùng CMS và plugin có cần lo không?

Có. Nhân CMS phổ biến thường có hàm truy vấn an toàn, nhưng plugin, theme hay mã tuỳ biến của bên thứ ba có thể không dùng đúng. Chỉ cài từ nguồn tin cậy, gỡ cái không dùng, cập nhật thường xuyên.

Mã hoá dữ liệu có ngăn được SQL injection không?

Không, vì câu lệnh bị chèn vẫn chạy với quyền của ứng dụng. Mã hoá cột nhạy cảm và băm mật khẩu đúng cách chỉ giảm giá trị của dữ liệu nếu bị lấy ra.

Tự thử SQL injection trên website người khác có vi phạm pháp luật không?

Có rủi ro pháp lý rõ ràng. Luật An ninh mạng số 116/2025/QH15 nghiêm cấm tấn công mạng, và truy cập trái phép có thể bị xử lý hành chính hoặc hình sự tuỳ mức độ. Nếu vô tình phát hiện lỗ hổng của tổ chức khác, hãy dừng lại và báo cho chủ hệ thống qua kênh chính thức.