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

Chi tiết kỹ thuật

Điểm yếu xảy ra khi sản phẩm ghép dữ liệu từ một thành phần thượng nguồn chịu ảnh hưởng bên ngoài vào đoạn mã, nhưng không kiểm soát đầy đủ các ký tự hoặc cấu trúc đặc biệt trong dữ liệu đó. Kẻ tấn công có thể làm thay đổi cú pháp, luồng điều khiển hoặc thao tác mà đoạn mã thực hiện, thay vì chỉ cung cấp dữ liệu thông thường. Vì mã được tạo có thể được thực thi với quyền của sản phẩm, tác động phụ thuộc vào ngữ cảnh và có thể vượt ra ngoài phạm vi xử lý đầu vào ban đầu.

Đặc điểm

Điểm cốt lõi của điểm yếu là dữ liệu chịu ảnh hưởng bên ngoài đi vào quá trình tạo mã, trong khi các phần tử đặc biệt có thể thay đổi cú pháp hoặc luồng điều khiển không được loại bỏ đúng cách. Điểm yếu thường xuất hiện khi mã được tạo động hoặc khi đầu vào được truyền tới các cơ chế đánh giá và thực thi mã. Hồ sơ cũng ghi nhận khả năng xuất hiện trong ngôn ngữ thông dịch và trong công nghệ AI/ML, nhưng không xác định mức phổ biến cho AI/ML.

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

Các tác động có thể gồm vượt qua cơ chế xác thực hoặc bảo vệ kiểm soát truy cập khi mã chèn kiểm soát việc xác thực, chiếm quyền hoặc giả mạo danh tính, và truy cập tài nguyên lẽ ra không được phép. Mã chèn có thể thực thi mã hoặc lệnh trái phép, ảnh hưởng đến tính bí mật, toàn vẹn và khả dụng; hồ sơ lưu ý rằng mất tính toàn vẹn thường có thể xảy ra vì dữ liệu mặt phẳng điều khiển được chèn vào không thuộc dữ liệu truy xuất hoặc ghi dự kiến. Hoạt động do mã điều khiển được chèn thực hiện cũng có thể không được ghi nhật ký, cho phép che giấu hành vi và ảnh hưởng đến khả năng quy trách nhiệm.

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

Tác động	Phạm vi	Diễn giải
Vượt qua cơ chế bảo vệ	Kiểm soát truy cập	In some cases, injectable code controls authentication; this may lead to a remote vulnerability.
Chiếm đặc quyền hoặc mạo danh	Kiểm soát truy cập	Injected code can access resources that the attacker is directly prevented from accessing.
Thực thi mã hoặc lệnh trái phép	Tính toàn vẹn, Tính bí mật, Tính sẵn sàng	When a product allows a user's input to contain code syntax, it might be possible for an attacker to craft the code in such a way that it will alter the intended control flow of the product. As a result, code injection can often result in the execution of arbitrary code. Code injection attacks can also lead to loss of data integrity in nearly all cases, since the control-plane data injected is always incidental to data recall or writing.
Che giấu hoạt động	Chống chối bỏ	Often the actions performed by injected control code are unlogged.

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

Tránh tạo mã động: Trong giai đoạn kiến trúc và thiết kế, tái cấu trúc chương trình để không cần sinh mã động.
Giới hạn môi trường thực thi: Chạy mã trong jail hoặc sandbox tương đương với ranh giới nghiêm ngặt giữa tiến trình và hệ điều hành. Hồ sơ nêu các ví dụ như Unix chroot và AppArmor. Biện pháp này có thể hạn chế mã được thực thi và giảm tác động lên hệ điều hành, nhưng có thể không khả thi, không ngăn việc xâm phạm phần còn lại của ứng dụng, và phải được thiết kế cẩn thận để tránh các điểm yếu liên quan đến jail như CWE-243.
Xác thực theo allowlist nghiêm ngặt: Coi mọi đầu vào là nguy hiểm và chỉ chấp nhận giá trị tuân thủ chặt chẽ đặc tả, bao gồm độ dài, kiểu, phạm vi, cú pháp, trường bắt buộc hoặc thừa, tính nhất quán và quy tắc nghiệp vụ. Với lời gọi được tạo động, chỉ kiểm tra đầu vào gồm chữ và số là chưa đủ, vì kẻ tấn công vẫn có thể tham chiếu một hàm nguy hiểm ngoài dự kiến như system, exec hoặc exit. Không nên dùng denylist làm biện pháp phòng vệ duy nhất, dù denylist có thể hỗ trợ phát hiện tấn công hoặc xác định đầu vào cần loại bỏ.
Kiểm thử với đầu vào đa dạng: Trong giai đoạn kiểm thử, sử dụng fuzzing, kiểm thử độ bền và fault injection với bộ đầu vào lớn, đa dạng. Sản phẩm không nên mất ổn định, bị lỗi hoặc tạo kết quả sai.
Dùng môi trường nhận biết taint: Trong vận hành, sử dụng môi trường tự động lan truyền taint và ngăn thực thi lệnh có biến bị đánh dấu taint, chẳng hạn tùy chọn -T của Perl. Vẫn phải xác thực đầu vào đúng cách, vì dữ liệu nguy hiểm có thể bị đánh dấu nhầm là không còn taint; hồ sơ dẫn chiếu CWE-183 và CWE-184 cho các vấn đề liên quan.
Lưu ý riêng với Python: ast.literal_eval thường được khuyến nghị thay cho eval vì được thiết kế để không thực thi mã. Tuy nhiên, hồ sơ không khuyến nghị xem đây là giải pháp chung cho dữ liệu không tin cậy, vì cấu trúc lồng sâu vẫn có thể gây tiêu thụ quá mức bộ nhớ hoặc ngăn xếp.

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

Tái cấu trúc · Kiến trúc và thiết kếRefactor your program so that you do not have to dynamically generate code.
Kiến trúc và thiết kếRun your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
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. To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Kiểm thửUse dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
Gia cố quá trình biên dịch hoặc xây dựng · Vận hànhRun the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Gia cố môi trường · Vận hànhRun the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Hiện thực hóa · Hiệu quả: Thực hành phổ biến không được khuyến nghịFor Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

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

Phân tích tĩnh tự động, thường gọi là SAST, có thể phát hiện một số trường hợp bằng cách phân tích mã nguồn hoặc mã đã biên dịch mà không cần thực thi. Phương pháp này thường lập mô hình luồng dữ liệu và luồng điều khiển, rồi tìm các mẫu nguy hiểm nối từ nguồn dữ liệu đầu vào đến các điểm đích nơi dữ liệu tương tác với thành phần bên ngoài hoặc tầng thấp hơn, chẳng hạn hệ điều hành; hồ sơ đánh giá phương pháp này có hiệu quả cao nhưng không khẳng định phát hiện được mọi 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	Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)	Cao

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

Các ví dụ dưới đây là ví dụ đại diện, không phải danh sách đầy đủ các lỗ hổng thuộc CWE này. Hồ sơ ghi nhận các nhóm sau:

CVE-2023-29374, CVE-2024-5565 và CVE-2024-4181: các framework hoặc thư viện LLM đưa đầu vào hoặc phản hồi chịu ảnh hưởng của người dùng vào biểu thức hay mã Python rồi chuyển cho exec hoặc eval, bao gồm các biến thể của prompt injection.
CVE-2022-2054, CVE-2007-1253 và CVE-2005-3302: thực thi chuỗi độc hại bằng eval trong chương trình hoặc trình biên dịch Python.
CVE-2021-22204: chuỗi điểm yếu bắt đầu từ việc xử lý regex không xác định đúng ranh giới chuỗi, dẫn đến eval injection; hồ sơ cho biết vụ việc đã bị khai thác thực tế theo CISA KEV.
CVE-2020-8218: code injection trong sản phẩm VPN, cũng được hồ sơ ghi nhận là bị khai thác thực tế theo CISA KEV.
CVE-2008-5071, CVE-2005-1921, CVE-2005-2498, CVE-2005-1876, CVE-2005-1894 và CVE-2003-0395: các trường hợp chèn mã hoặc eval injection trong chương trình, câu lệnh hoặc tệp hỗ trợ PHP.
CVE-2008-5305, CVE-2002-1750, CVE-2002-1752, CVE-2002-1753, CVE-2005-1527, CVE-2005-2837 và CVE-2002-0495: các trường hợp chèn mã hoặc eval injection trong chương trình, hàm eval hoặc tệp thư viện Perl.
CVE-2001-1471: chuỗi điểm yếu trong đó giá trị không hợp lệ ảnh hưởng đến việc khởi tạo biến, sau đó biến bị kẻ tấn công sửa đổi và đưa vào câu lệnh eval của PHP.

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-94, dựa theo mức độ ưu tiên

Nguồn (2)

MITRE CWE

CWE Terms of Use

CWE-94: Kiểm soát không phù hợp việc tạo mã ("Code Injection")

CWE-94 là gì?

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

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

Đị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