Định nghĩa chính thức

Chi tiết kỹ thuật

Sản phẩm nhận dữ liệu chịu ảnh hưởng từ bên ngoài qua một thành phần upstream và dùng dữ liệu đó để tạo lệnh SQL gửi tới thành phần downstream. Khi dữ liệu và cú pháp điều khiển không được tách biệt bằng cơ chế phù hợp, các ký tự hoặc cấu trúc SQL trong đầu vào có thể thay đổi ý nghĩa truy vấn ban đầu. Lỗi này thường bắt nguồn từ việc ghép chuỗi truy vấn động, quoting hoặc escaping không đúng, và có thể xảy ra ngay cả khi đầu vào được kỳ vọng là ID số, tên người dùng, mật khẩu hoặc một trường nghiệp vụ khác.

Đặc điểm

Điểm yếu hình thành trong giai đoạn triển khai, thường xuất hiện ở các ứng dụng giàu dữ liệu có lưu đầu vào người dùng vào cơ sở dữ liệu. Nó không phụ thuộc vào một ngôn ngữ cụ thể, nhưng thường liên quan đến SQL và máy chủ cơ sở dữ liệu, khi dữ liệu từ thành phần upstream được đưa vào lệnh gửi tới thành phần downstream mà không duy trì ranh giới giữa dữ liệu và cú pháp. SQL injection có thể xuất hiện qua nhiều loại trường đầu vào, không chỉ trường được dự kiến là số, và có thể ảnh hưởng tới cả ứng dụng trực tiếp lẫn thư viện hoặc API trung gian.

Hậu quả thường gặp

Hậu quả tiềm tàng bao gồm mất tính bí mật, toàn vẹn, khả dụng, xác thực và kiểm soát truy cập. Kẻ tấn công có thể đọc dữ liệu nhạy cảm của ứng dụng, sửa hoặc xóa nội dung cơ sở dữ liệu, vượt qua xác thực hoặc phân quyền, chiếm danh tính hay đặc quyền của người dùng khác, và trong một số môi trường thực thi lệnh trái phép bằng cách chuyển hướng kết quả SQL vào tệp có thể thực thi. Tác động thực tế phụ thuộc vào khả năng của cơ sở dữ liệu, quyền của tài khoản ứng dụng, các truy vấn bị ảnh hưởng và mức độ nhạy cảm của dữ liệu có thể truy cập.

Dữ liệu MITRE CWE chính thức

Tác động	Phạm vi	Diễn giải
Thực thi mã hoặc lệnh trái phép	Tính bí mật, Tính toàn vẹn, Tính sẵn sàng	Adversaries could execute system commands, typically by changing the SQL statement to redirect output to a file that can then be executed.
Đọc dữ liệu ứng dụng	Tính bí mật	Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.
Chiếm đặc quyền hoặc mạo danh, Vượt qua cơ chế bảo vệ	Xác thực	If poor SQL commands are used to check user names and passwords or perform other kinds of authentication, it may be possible to connect to the product as another user with no previous knowledge of the password.
Vượt qua cơ chế bảo vệ	Kiểm soát truy cập	If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability.
Thay đổi dữ liệu ứng dụng	Tính toàn vẹn	Just as it may be possible to read sensitive information, it is also possible to modify or even delete this information with a SQL injection attack.

Biện pháp giảm thiểu rủi ro

Tách biệt dữ liệu khỏi mã. Ưu tiên các thư viện hoặc framework bền vững đã được kiểm chứng, cung cấp cấu trúc truy cập cơ sở dữ liệu an toàn, chẳng hạn Hibernate hoặc Enterprise Java Beans khi được sử dụng đúng cách. Xử lý SQL bằng prepared statement, truy vấn tham số hóa hoặc stored procedure có kiểu dữ liệu chặt chẽ; không tạo và thực thi động chuỗi truy vấn bên trong các cơ chế này bằng exec hoặc chức năng tương tự.

Giới hạn đầu vào và ánh xạ giá trị. Coi mọi dữ liệu bên ngoài là độc hại và dùng allowlist nghiêm ngặt cho kiểu, độ dài, cú pháp, miền giá trị, tính nhất quán giữa các trường và quy tắc nghiệp vụ. Kiểm tra đầu vào chỉ là lớp phòng vệ bổ sung, không thay thế cho việc mã hóa, escape và quoting đúng cách, đặc biệt với trường văn bản tự do. Khi tập đối tượng hợp lệ đã biết, ánh xạ các giá trị đầu vào cố định như ID số tới đối tượng tương ứng và từ chối các giá trị khác. Lặp lại mọi kiểm tra bảo mật phía máy khách ở phía máy chủ.

Bảo vệ trường hợp buộc phải tạo động. Nếu không thể tránh tạo truy vấn động, hãy quote đúng các đối số và escape ký tự đặc biệt. Dùng allowlist chặt nhất có thể, cùng các cơ chế của cơ sở dữ liệu hoặc ngôn ngữ như DBMS_ASSERT của Oracle hoặc API mysql_real_escape_string của MySQL khi phù hợp. Cách này vẫn có rủi ro và phải tính đến cả việc chèn đối số.

Giảm tác động và rò rỉ thông tin. Chạy tài khoản cơ sở dữ liệu theo nguyên tắc đặc quyền tối thiểu, tốt nhất là các tài khoản cô lập chỉ phục vụ một nhiệm vụ, và chỉ cấp quyền tối thiểu trên các đối tượng cơ sở dữ liệu. Không chạy ứng dụng cơ sở dữ liệu thông thường bằng tài khoản quản trị; giới hạn truy cập vào dữ liệu mà bên gọi được phép sử dụng và áp dụng quyền nghiêm ngặt nhất cho stored procedure. Thông báo lỗi phải tối thiểu, không tiết lộ cấu trúc truy vấn SQL hoặc trạng thái nội bộ; chi tiết cần thiết nên được ghi vào log được bảo vệ phù hợp và tuyệt đối không ghi mật khẩu. Với PHP, không sử dụng register_globals và không mô phỏng tính năng này theo cách tạo ra các điểm yếu liên quan.

Bổ sung phòng vệ vận hành. Application firewall có thể phát hiện và chặn cuộc tấn công khi chưa thể sửa mã ngay, hoặc cung cấp bảo vệ khẩn cấp trong lúc áp dụng các biện pháp bảo đảm phần mềm toàn diện hơn. Tuy nhiên, phạm vi bao phủ của nó có giới hạn, có thể bị vượt qua, làm ảnh hưởng yêu cầu hợp lệ hoặc cần tùy chỉnh.

Dữ liệu MITRE CWE chính thức

Thư viện hoặc framework · Kiến trúc và thiết kếUse a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
Tham số hóa · Kiến trúc và thiết kếIf available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]
Gia cố môi trường · Kiến trúc và thiết kế, Vận hànhRun your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations. Specifically, follow the principle of least privilege when creating user accounts to a SQL database. The database users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot read/write others' data. Use the strictest permissions possible on all database objects, such as execute-only for stored procedures.
Kiến trúc và thiết kếFor any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mã hóa ký tự đầu ra · Hiện thực hóaWhile it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88). Instead of building a new implementation, such features may be available in the database or programming language. For example, the Oracle DBMS_ASSERT package can check or enforce that parameters have certain properties that make them less vulnerable to SQL injection. For MySQL, the mysql_real_escape_string() API function is available in both C and PHP.
Kiểm tra dữ liệu đầu vào · Hiện thực hóaAssume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When constructing SQL query strings, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping. Note that proper output encoding, escaping, and quoting is the most effective solution for preventing SQL injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent SQL injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, the name "O'Reilly" would likely pass the validation step, since it is a common last name in the English language. However, it cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise handled. In this case, stripping the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded. When feasible, it may be safest to disallow meta-characters entirely, instead of escaping them. This will provide some defense in depth. After the data is entered into the database, later processes may neglect to escape meta-characters before use, and you may not have control over those processes.
Áp đặt quy tắc bằng chuyển đổi · Kiến trúc và thiết kếWhen the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
Hiện thực hóaEnsure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. In the context of SQL Injection, error messages revealing the structure of a SQL query can help attackers tailor successful attack strings.
Tường lửa · Vận hành · Hiệu quả: KháUse an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481.An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.
Gia cố môi trường · Vận hành, Hiện thực hóaWhen using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Cách phát hiện trong hệ thống

Có thể phát hiện bằng nhiều phương pháp: phân tích tĩnh tự động ở mã nguồn, bytecode hoặc binary; phân tích động tự động bằng fuzzing, kiểm thử độ bền, fault injection, database scanner, web application scanner và web services scanner; phân tích thủ công mã nguồn hoặc thiết kế; cùng với phân tích kết quả thủ công từ fuzz tester và framework-based fuzzer. Phân tích tĩnh có thể tạo cảnh báo giả khi không nhận diện được kiểm tra đầu vào hợp lệ, hoặc bỏ sót API tùy chỉnh và thư viện bên thứ ba; không phương pháp nào bảo đảm độ chính xác và độ bao phủ tuyệt đối, còn phân tích thủ công có thể bị giới hạn bởi thời gian và kích thước bề mặt tấn công. Các kỹ thuật được hồ sơ đánh giá có hiệu quả cao gồm phân tích yếu điểm mã nguồn, phân tích bytecode hoặc binary, database scanner, rà soát mã nguồn thủ công và rà soát kiến trúc hoặc thiết kế; fuzzing và các scanner ứng dụng hoặc dịch vụ web chỉ có độ bao phủ một phần trong một số trường hợp.

Dữ liệu MITRE CWE chính thức

Phương pháp	Cách làm	Hiệu quả
Phân tích tĩnh tự động	This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives. Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or do not require any code changes. Automated static analysis might not be able to detect the usage of custom API functions or third-party libraries that indirectly invoke SQL commands, leading to false negatives - especially if the API/library code is not available for analysis.This is not a perfect solution, since 100% accuracy and coverage are not feasible.	-
Phân tích động tự động	This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.	Khá
Phân tích thủ công	Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.	-
Phân tích tĩnh tệp nhị phân hoặc bytecode tự động	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis	Cao
Phân tích động với diễn giải kết quả tự động	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Database Scanners ``` Cost effective for partial coverage: ``` Web Application Scanner Web Services Scanner	Cao
Phân tích động với diễn giải kết quả thủ công	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Fuzz Tester Framework-based Fuzzer	SOAR một phần
Phân tích tĩnh mã nguồn thủ công	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Manual Source Code Review (not inspections) ``` Cost effective for partial coverage: ``` Focused Manual Spotcheck - Focused manual analysis of source	Cao
Phân tích tĩnh mã nguồn tự động	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer	Cao
Rà soát kiến trúc hoặc thiết kế	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Formal Methods / Correct-By-Construction ``` Cost effective for partial coverage: ``` Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)	Cao

Lỗ hổng điển hình

Các ví dụ sau là những trường hợp đại diện được hồ sơ ghi nhận, không phải danh sách đầy đủ:

CVE-2024-6847: SQL injection trong chatbot AI thông qua tin nhắn hội thoại.
CVE-2025-26794: SQL injection trong tác nhân email thông qua tích hợp SQLite.
CVE-2023-32530: SQL injection trong bảng điều khiển sản phẩm bảo mật qua các trường chứng thư được tạo đặc biệt.
CVE-2021-42258, CVE-2021-27101 và CVE-2020-12271: các trường hợp trong phần mềm chấm công và tính phí, hệ thống truyền tệp và giao diện quản trị hoặc cổng người dùng của sản phẩm tường lửa; hồ sơ ghi nhận chúng đã bị khai thác trong thực tế.
CVE-2019-3792: API trong hệ thống tự động hóa viết bằng Go cho phép đọc dữ liệu đặc quyền.
CVE-2004-0366: chuỗi lỗi trong thư viện xác thực cơ sở dữ liệu dẫn tới SQL injection và vượt qua xác thực.
CVE-2008-2790 và CVE-2008-2223: SQL injection qua ID vốn được dự kiến là số.
CVE-2007-6602 và CVE-2008-5817: SQL injection qua trường tên người dùng hoặc tên người dùng và mật khẩu.
CVE-2003-0377, CVE-2008-2380 và CVE-2017-11508: các trường hợp trong sản phẩm bảo mật, thư viện xác thực và công cụ quản lý hoặc báo cáo lỗ hổng, lần lượt liên quan đến tên nhóm, thư viện xác thực và mật khẩu được tạo đặc biệt.

Dữ liệu MITRE CWE chính thức

Dưới đây là các lỗ hổng tiêu biểu liên quan đến CWE-89, dựa theo mức độ ưu tiên

Nguồn (2)

MITRE CWE

CWE Terms of Use

CWE-89: Vô hiệu hóa không đúng các phần tử đặc biệt được sử dụng trong lệnh SQL ('SQL Injection')

CWE-89 là gì?

Số lượng lỗ hổng nằm trong CWE-89

Số lượng lỗ hổng trong CISA KEV của CWE-89

Định nghĩa chính thức

Chi tiết kỹ thuật

Đặc điểm

Hậu quả thường gặp

Biện pháp giảm thiểu rủi ro

Cách phát hiện trong hệ thống

Lỗ hổng điển hình

Tài liệu bổ trợ

Kiểm tra chuyên sâu cùng giải pháp quản lý rủi ro Web toàn diện

Tìm hiểu các tài nguyên khác từ CyStack

Báo cáo độ an toàn trang Web

Nghiên cứu của CyStack

Kiến thức về An ninh mạng