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

TheoMitre CWE

Đặc điểm

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

Tên gọi khác

Zip Slip — "Zip slip" is an attack that uses file archives (e.g., ZIP, tar, rar, etc.) that contain filenames with path traversal sequences that cause the files to be written outside of the directory under which the archive is expected to be extracted [REF-1282]. It is most commonly used for relative path traversal (CWE-23) and link following (CWE-59).

Giai đoạn hình thành

Hiện thực hóa

Hậu quả thường gặ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 toàn vẹn, Tính bí mật, Tính sẵn sàng	The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.
Thay đổi tệp hoặc thư mục	Tính toàn vẹn	The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication.
Đọc tệp hoặc thư mục	Tính bí mật	The attacker may be able read the contents of unexpected files and expose sensitive data by traversing the file system to access files or directories that are outside of the restricted directory. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.
Từ chối dịch vụ: sập, thoát hoặc khởi động lại	Tính sẵn sàng	The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the product from working at all and in the case of a protection mechanisms such as authentication, it has the potential to lockout every user of the product.

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

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

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 validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Kiểm tra dữ liệu đầu vào · Hiện thực hóaInputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked. Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes: - realpath() in C - getCanonicalPath() in Java - GetFullPath() in ASP.NET - realpath() or abs_path() in Perl - realpath() in PHP
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.

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

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

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

Nguồn (2)

MITRE CWE

CWE Terms of Use

CWE-23: Relative Path Traversal

CWE-23 là gì?

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

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

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

Đặc điểm

Tên gọi khác

Giai đoạn hình thành

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