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

Chi tiết kỹ thuật

Khi đầu vào không được tách biệt rõ khỏi cú pháp mã, nội dung do tác nhân kiểm soát có thể được trình đánh giá động diễn giải như chỉ thị thực thi thay vì như dữ liệu. Việc xác thực không đầy đủ, chuẩn hóa không đúng hoặc các bước giải mã lặp lại có thể cho phép cú pháp nguy hiểm xuất hiện sau thời điểm kiểm tra. Điểm yếu thường bắt nguồn từ việc dùng đánh giá động để phân phối lời gọi hàm hoặc thiết lập biến, và có thể ảnh hưởng đến các chương trình trong Java, JavaScript, Python, Perl, PHP, Ruby cũng như các môi trường thông dịch khác.

Đặc điểm

Điểm cốt lõi của điểm yếu là dữ liệu từ bên ngoài được đưa vào cú pháp hoặc chỉ thị của mã được đánh giá động, thay vì chỉ được xử lý như dữ liệu. Điểm yếu thường xuất hiện trong các thủ tục xử lý hoặc phân phối cần gọi nhiều hàm hay thiết lập nhiều biến, và được hình thành trong giai đoạn triển khai. CWE này áp dụng cho các ngôn ngữ thông dịch như Java, JavaScript, Python, Perl, PHP và Ruby; bản ghi cũng xác định công nghệ AI/ML là môi trường thường gặp.

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

Mã được chèn có thể đọc tệp, thư mục hoặc dữ liệu ứng dụng bị hạn chế, vượt qua cơ chế bảo vệ, nâng quyền hoặc giả danh người khác. Nó có thể thực thi mã hoặc lệnh trái phép và thay đổi hành vi ứng dụng, có khả năng ảnh hưởng đến tính bí mật, toàn vẹn và khả dụng. Các hành động do mã điều khiển được chèn thực hiện có thể không được ghi nhật ký, khiến hoạt động bị che giấu; trong một số trường hợp, mã chèn có thể kiểm soát xác thực và tạo thành điểm yếu có thể khai thác từ xa.

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

Tác động	Phạm vi	Diễn giải
Đọc tệp hoặc thư mục, Đọc dữ liệu ứng dụng	Tính bí mật	The injected code could access restricted data / files.
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, Khác	Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code or at least modify what code can be executed.
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

Loại bỏ đánh giá động. Ở giai đoạn kiến trúc và triển khai, tái cấu trúc thiết kế để không cần dùng eval hoặc cơ chế đánh giá mã động tương đương.

Xác thực theo allowlist nghiêm ngặt. Coi mọi đầu vào là có thể độc hại và chỉ chấp nhận các giá trị tuân thủ chặt chẽ đặc tả. Kiểm tra độ dài, kiểu, toàn bộ miền giá trị hợp lệ, trường bị thiếu hoặc thừa, cú pháp, tính nhất quán giữa các trường liên quan và quy tắc nghiệp vụ. Từ chối đầu vào không phù hợp hoặc chuyển đổi nó thành biểu diễn phù hợp. Không chỉ dựa vào denylist, dù denylist vẫn có thể hỗ trợ phát hiện tấn công hoặc loại bỏ đầu vào rõ ràng bất thường.

Chuẩn hóa trước khi xác thực. Giải mã và chuẩn hóa đầu vào về biểu diễn nội bộ hiện tại của ứng dụng trước khi xác thực. Tránh giải mã cùng một đầu vào nhiều lần, vì giải mã hai lần hoặc lỗi tương tự có thể vượt qua allowlist. Có thể sử dụng các thư viện kiểm soát chuẩn hóa như OWASP ESAPI Canonicalization. Chuẩn hóa lặp lại cho đến khi đầu vào không còn thay đổi có thể xử lý giải mã hai lần, nhưng cũng có thể sửa đổi những đầu vào hợp lệ vốn chứa nội dung nguy hiểm đã được mã hóa.

Lưu ý riêng cho Python. ast.literal_eval thường được đề xuất thay cho eval vì được thiết kế để không thực thi mã. Tuy nhiên, đầu vào lồng sâu vẫn có thể gây tiêu thụ quá mức bộ nhớ hoặc ngăn xếp, và tài liệu Python không khuyến nghị dùng hàm này với dữ liệu không đáng tin cậy.

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

Tái cấu trúc · Kiến trúc và thiết kế, Hiện thực hóaIf possible, refactor your code so that it does not need to use eval() at all.
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.
Hiện thực hóaInputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
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 được gọi là SAST, có thể phát hiện một số trường hợp bằng cách lập mô hình luồng dữ liệu và luồng điều khiển, rồi tìm các đường đi nối nguồn đầu vào với các điểm đích thực hiện đánh giá động hoặc tương tác với thành phần bên ngoài. Phương pháp này có hiệu quả cao nhưng không đảm bảo phát hiện mọi trường hợp, đặc biệt khi việc tạo mã hoặc luồng dữ liệu khó suy luận tĩnh.

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ụ sau là một số ví dụ đại diện, không phải danh sách đầy đủ:

CVE-2024-4181: Một framework cho ứng dụng LLM cho phép chèn eval thông qua phản hồi được tạo bởi nhà cung cấp lưu trữ.
CVE-2022-2054: Trình biên dịch Python dùng eval để thực thi chuỗi độc hại dưới dạng mã Python.
CVE-2021-22204: Chuỗi khai thác kết hợp với CWE-625, trong đó bộ xử lý EXIF xác định sai điểm kết thúc chuỗi, dẫn đến chèn eval; việc khai thác ngoài thực tế được ghi nhận trong CISA KEV.
CVE-2021-22205: Chuỗi khai thác kết hợp với CWE-20, trong đó dấu gạch chéo ngược theo sau bởi dòng mới vượt qua bước xác thực và dẫn đến chèn eval; việc khai thác ngoài thực tế được ghi nhận trong CISA KEV.
CVE-2008-5071: Chèn eval trong chương trình PHP.
CVE-2002-1750, CVE-2008-5305, CVE-2002-1752, CVE-2002-1753: Các trường hợp chèn eval hoặc chèn mã trực tiếp vào hàm eval trong chương trình Perl, gồm trường hợp dùng mã định danh lẽ ra chỉ chứa dấu gạch nối và chữ số.
CVE-2005-1527, CVE-2005-2837: Chèn mã trực tiếp vào hàm eval của Perl.
CVE-2005-1921, CVE-2005-2498: Chèn mã vào câu lệnh eval của PHP bằng các cấu trúc lồng nhau vốn không được phép lồng.
CVE-2005-3302, CVE-2007-1253: Chèn mã vào câu lệnh eval của Python, gồm trường hợp bắt nguồn từ một trường trong tệp có định dạng.
CVE-2001-1471: Chuỗi khai thác trong đó giá trị không hợp lệ ngăn việc khởi tạo biến; kẻ tấn công có thể sửa các biến rồi đưa chúng vào câu lệnh eval của PHP.
CVE-2007-2713: Chuyển hướng thực thi dẫn đến chèn eval.

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

Nguồn (2)

MITRE CWE

CWE Terms of Use

CWE-95: Vô hiệu hóa không đúng các chỉ thị trong mã được đánh giá động ("Chèn mã Eval")

CWE-95 là gì?

Xác minh để phân tích mục CWE này

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

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

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