CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

CWE-22 là gì?

CWE-22 là Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'). Lỗi phát sinh khi the product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. Hiện có 1.691 lỗ hổng trong kho dữ liệu liên quan đến CWE-22 và 9 trong số đó nằm trong danh mục khai thác thực tế của CISA.

Đang phân tích dữ liệu...

THỨ HẠNG OWASP TOP 10:20251 — A01:2025 — Broken Access Control
Tổng số CVE liên quan (365 ngày)1.691
Mức trừu tượngCơ bản
Khả năng khai thácCao

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

1.691 lỗ hổngTăng 453% so với cùng kỳ

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

9 lỗ hổngTăng 125% so với cùng kỳ

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

  • Path traversal — "Path traversal" is preferred over "directory traversal," but both terms are attack-focused.
  • Directory traversal
  • Path transversal — an alternate phrasing of "path traversal"

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 độngPhạm viDiễn giải
Thực thi mã hoặc lệnh trái phépTính toàn vẹn, Tính bí mật, Tính sẵn sàngThe 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ụcTính toàn vẹnThe 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ụcTính bí mậtThe attacker may be able read the contents of unexpected files and expose sensitive data. 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ạiTính sẵn sàngThe 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 protection mechanisms such as authentication, it has the potential to lock out product users.

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

Dữ liệu MITRE CWE chính thức
  1. 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.
  2. 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.
  3. 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
  4. 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].
  5. 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.
  6. 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.
  7. Á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. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability.
  8. Môi trường cô lập (sandbox/jail) · Kiến trúc và thiết kế, Vận hành · Hiệu quả: Hạn chếRun the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.
  9. Giảm bề mặt tấn công · Kiến trúc và thiết kế, Vận hànhStore library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately. This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.
  10. 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 path traversal, error messages which disclose path information can help attackers craft the appropriate attack strings to move through the file system hierarchy.
  11. 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

Dữ liệu MITRE CWE chính thức
Phương phápCách làmHiệu quả
Phân tích tĩnh tự độngAutomated techniques can find areas where path traversal weaknesses exist. However, tuning or customization may be required to remove or de-prioritize path-traversal problems that are only exploitable by the product's administrator - or other privileged users - and thus potentially valid behavior or, at worst, a bug instead of a vulnerability.Cao
Phân tích tĩnh thủ côngManual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all file access operations can be assessed within limited time constraints.Cao
Phân tích tĩnh tệp nhị phân hoặc bytecode tự độngAccording to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis ``` Cost effective for partial coverage: ``` Binary Weakness Analysis - including disassembler + source code weakness analysisCao
Phân tích tĩnh tệp nhị phân hoặc bytecode thủ côngAccording to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomaliesSOAR một phần
Phân tích động với diễn giải kết quả tự độngAccording to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Web Application Scanner Web Services Scanner Database ScannersCao
Phân tích động với diễn giải kết quả thủ côngAccording to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Fuzz Tester Framework-based FuzzerCao
Phân tích tĩnh mã nguồn thủ côngAccording 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 sourceCao
Phân tích tĩnh mã nguồn tự độngAccording to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Source code Weakness Analyzer Context-configured Source Code Weakness AnalyzerCao
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

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

Nguồn (2)
MITRE CWE
CWE Terms of Use

Tài liệu bổ trợ

CWE™ Program, operated by The MITRE Corporation. Copyright © 2006–2026, The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. CWE Terms of Use.

Tìm hiểu thêm

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

Giải pháp CyStack VulnScan liên tục phát hiện tài sản, xác minh lỗ hổng và giúp đội ngũ bảo mật ưu tiên khắc phục cho toàn bộ doanh nghiệp.

Khám phá CyStack VulnScan
Tài nguyên & Thông tin khác

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

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

Đánh giá mức độ an toàn và các đề xuất tới từ CyStack cho các trang Web

Xem thêm

Nghiên cứu của CyStack

Tìm hiểu các nghiên cứu của đội ngũ chuyên gia chúng tôi trong an ninh mạng

Xem thêm

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

Tìm hiểu về giải pháp tình báo mối đe doạ và phát hiện lộ lọt dữ liệu tới từ CyStack

Xem thêm