CWE-22: Giới hạn không đúng tên đường dẫn vào thư mục bị hạn chế ('Path Traversal')

CWE-22 là gì?

Sản phẩm sử dụng dữ liệu đầu vào bên ngoài để tạo tên đường dẫn vốn phải nằm dưới một thư mục cha bị hạn chế, nhưng không vô hiệu hóa đúng các phần tử đặc biệt khiến đường dẫn có thể được phân giải ra ngoài thư mục đó.

Thống kê 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.251
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.251 lỗ hổngTăng 402,4% so với cùng kỳ

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

7 lỗ hổngTăng 133,3% so với cùng kỳ

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

TheoMitre CWE

Chi tiết kỹ thuật

Path traversal xảy ra khi quá trình xử lý tên đường dẫn cho phép đường dẫn do kẻ tấn công kiểm soát vượt ra khỏi ranh giới thư mục dự kiến. Dạng tương đối thường sử dụng .. cùng dấu phân cách /, còn dạng tuyệt đối cung cấp toàn bộ tên đường dẫn như /usr/local/bin; bản ghi cũng bao quát việc xử lý đường dẫn phụ thuộc nền tảng. Vì vậy, thao tác có thể tác động đến các tệp hoặc thư mục ở nơi khác trên hệ thống thay vì chỉ trong vị trí bị hạn chế.

Đặc điểm

Đây là một điểm yếu cơ sở, đơn giản, thường phát sinh trong giai đoạn triển khai khi dữ liệu bên ngoài được dùng trong thao tác với tệp hoặc thư mục mà thiếu kiểm tra, giải mã, chuẩn hóa tên đường dẫn hoặc thực thi ranh giới phù hợp. Điểm yếu có thể xuất hiện qua đường dẫn tương đối hoặc tuyệt đối, giải nén lưu trữ, siêu dữ liệu tải lên, lệnh quản lý tệp, tệp được đưa vào và các giao diện tương tự. Bản ghi ưu tiên thuật ngữ path traversal hơn directory traversal, đồng thời vẫn liệt kê cả hai thuật ngữ và cách gọi path transversal.

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

Hậu quả tiềm tàng bao gồm tính bí mật, tính toàn vẹn và tính sẵn sàng. Kẻ tấn công có thể đọc các tệp ngoài dự kiến, tạo hoặc ghi đè chương trình, thư viện, dữ liệu quan trọng hoặc tệp liên quan đến cơ chế bảo mật, từ đó có khả năng vượt qua xác thực hoặc thực thi mã hay lệnh trái phép. Việc ghi đè, xóa hoặc làm hỏng các tệp quan trọng cũng có thể khiến sản phẩm bị dừng, khởi động lại, không hoạt động hoặc khóa người dùng.

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

Áp dụng các biện pháp nhiều lớp theo đúng nội dung bản ghi chính thức:

  • Kiểm tra nghiêm ngặt: Coi mọi đầu vào là độc hại và dùng allowlist theo nguyên tắc chấp nhận dữ liệu hợp lệ, bao quát độ dài, kiểu, cú pháp, giá trị cho phép, tính nhất quán giữa các trường và quy tắc nghiệp vụ. Với tên tệp, giới hạn tập ký tự, nếu khả thi chỉ cho phép một dấu ., loại bỏ dấu phân cách thư mục và giới hạn phần mở rộng. Không chỉ dựa vào denylist hoặc xóa ký tự nguy hiểm, vì dấu phân cách khác và các cách vượt qua khác vẫn có thể tồn tại.
  • Chuẩn hóa trước khi kiểm tra: Giải mã và chuẩn hóa đầu vào một lần về biểu diễn nội bộ của ứng dụng trước khi kiểm tra. Sử dụng hàm chuẩn hóa dựng sẵn như realpath trong C hoặc PHP, getCanonicalPath trong Java, GetFullPath trong ASP.NET hoặc abs_path trong Perl, đồng thời xử lý các chuỗi .. và liên kết tượng trưng.
  • Thực thi kiểm tra ở máy chủ: Lặp lại các kiểm tra bảo mật trên máy chủ nếu phía máy khách cũng kiểm tra, vì phía máy khách có thể bị sửa đổi hoặc bỏ qua.
  • Ưu tiên thiết kế an toàn hơn: Dùng thư viện hoặc framework đã được thẩm định. Khi tập tên tệp hoặc URL hợp lệ là hữu hạn hay đã biết, ánh xạ các mã định danh cố định tới các đối tượng đó và từ chối đầu vào khác, chẳng hạn ánh xạ ID số tới tên tệp cố định.
  • Giảm tác động và bề mặt lộ diện: Chạy với đặc quyền thấp nhất cần thiết, dùng các tài khoản cô lập chỉ có quyền hạn chế cho từng nhiệm vụ, và đặt tệp thư viện, include và tiện ích ngoài thư mục gốc của web khi có thể. Nếu không, dùng kiểm soát truy cập của máy chủ và biện pháp ngăn yêu cầu trực tiếp.
  • Bổ sung phòng vệ vận hành: Tường lửa ứng dụng có thể cung cấp biện pháp khẩn cấp hoặc phòng thủ nhiều lớp, nhất là khi chưa thể sửa mã ngay, nhưng có thể bỏ sót vector, bị vượt qua, từ chối yêu cầu hợp lệ hoặc cần tùy chỉnh. Sandbox hoặc jail như Unix chroot, AppArmor, SELinux hoặc Java java.io.FilePermission có thể hạn chế tệp hay lệnh được truy cập, nhưng hiệu quả có giới hạn và phụ thuộc triển khai cụ thể; chúng có thể chỉ thu hẹp phạm vi tác động và cần tránh các điểm yếu liên quan đến jail.
  • Hạn chế rò rỉ thông tin: Giữ thông báo lỗi ở mức chi tiết tối thiểu, không tiết lộ thông tin đường dẫn hệ thống tệp hoặc phương pháp kiểm tra. Nếu cần ghi chi tiết, phải cân nhắc khả năng kẻ tấn công xem được log và không lưu thông tin rất nhạy cảm như mật khẩu.
  • Biện pháp riêng cho PHP: Không sử dụng register_globals và không xây dựng cơ chế mô phỏng không an toàn cho tính năng này.
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

Bản ghi chính thức xác định nhiều phương pháp phát hiện bổ trợ cho nhau:

  • Phân tích mã nguồn và mã thực thi: Phân tích tĩnh tự động cùng các công cụ phân tích điểm yếu mã nguồn, bao gồm công cụ được cấu hình theo ngữ cảnh, có hiệu quả cao nhưng có thể cần tinh chỉnh. Rà soát mã nguồn thủ công và kiểm tra có trọng tâm có thể cung cấp độ bao phủ hữu ích; phân tích tĩnh thủ công có thể giảm cảnh báo sai khi có thể đánh giá mọi thao tác truy cập tệp trong thời gian cho phép.
  • Phân tích nhị phân và bytecode: Phân tích điểm yếu bytecode tự động, gồm dịch ngược cùng phân tích điểm yếu mã nguồn, có hiệu quả chi phí cao. Phân tích điểm yếu nhị phân và dịch ngược nhị phân hoặc bytecode thủ công rồi rà soát thủ công cung cấp độ bao phủ một phần với chi phí hiệu quả.
  • Kiểm thử động: Công cụ quét ứng dụng web, dịch vụ web và cơ sở dữ liệu, cùng bộ kiểm thử fuzz và fuzz theo framework, được xác định là có hiệu quả chi phí cao. Kết quả vẫn phụ thuộc vào đường đi, đầu vào và chức năng được kiểm thử.
  • Rà soát kiến trúc và thiết kế: Phương pháp hình thức hoặc thiết kế đúng ngay từ đầu có hiệu quả chi phí cao, còn kiểm tra theo tiêu chuẩn IEEE 1028 có thể cung cấp độ bao phủ một phần với chi phí hiệu quả cho yêu cầu, thiết kế và mã nguồn.

Các kỹ thuật tự động có thể cần tùy chỉnh để phân biệt hành vi chỉ dành cho quản trị viên hoặc người có đặc quyền với điểm yếu có thể khai thác. Không có phương pháp đơn lẻ nào được nêu là bảo đảm bao phủ đầy đủ.

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

Bản ghi chính thức liệt kê các ví dụ tiêu biểu, không phải danh sách đầy đủ:

  • CVE-2024-37032: Công cụ quản lý LLM cho phép traversal tương đối do không kiểm tra digest từ registry mô hình không đáng tin cậy.
  • CVE-2024-4315: API tạo văn bản bằng LLM bỏ sót dấu phân cách Windows \ trong denylist, cho phép xóa tệp tùy ý trên Windows.
  • CVE-2024-0520: Sản phẩm quản lý tập dữ liệu AI cho phép traversal tương đối và tuyệt đối qua Content-Disposition để ghi đè tệp.
  • CVE-2022-45918: Trình gỡ lỗi của công cụ quản lý học tập dùng đường dẫn kiểm tra không đầy đủ để tìm log phiên qua chuỗi ../.
  • CVE-2019-20916: Trình quản lý gói Python cho phép đọc tệp tùy ý qua traversal trong tên tệp Content-Disposition.
  • CVE-2022-31503: Việc dùng os.path.join không an toàn trong Python cho phép đường dẫn tuyệt đối từ đầu vào thay thế tên đường dẫn dự kiến.
  • CVE-2022-24877: Operator Kubernetes viết bằng Go cho phép truy cập tệp trong pod điều khiển qua ../ trong YAML.
  • CVE-2021-21972: Tải lên lưu trữ không yêu cầu xác thực kết hợp với traversal .. để truy cập tệp ngoài dự kiến; bản ghi cho biết lỗi này đã bị khai thác ngoài thực tế.
  • CVE-2020-4053 và CVE-2019-10743: Xử lý gói hoặc lưu trữ trong Go cho phép sao chép hoặc giải nén tệp từ plugin hay archive ZIP độc hại ra ngoài thư mục dự kiến, thường gọi là Zip Slip.
  • CVE-2020-3452: Kiểm tra đầu vào không đúng trong sản phẩm bảo mật dẫn đến directory traversal; bản ghi cho biết lỗi này đã bị khai thác ngoài thực tế.
  • CVE-2010-0467: Mô-đun bản tin cho phép đọc tệp tùy ý qua ../.
  • CVE-2006-7079: Lớp tương thích PHP dùng extract cho khả năng tương thích register_globals, từ đó cho phép traversal.
  • CVE-2009-4194, CVE-2009-4053 và CVE-2009-0244: Các dịch vụ liên quan đến FTP cho phép xóa tệp tùy ý, tạo thư mục, liệt kê thư mục hoặc đọc tệp qua chuỗi ...
  • CVE-2009-4013 và CVE-2010-0012: Xử lý gói hoặc torrent cho phép ghi đè tệp tùy ý qua .. hoặc ../.
  • CVE-2010-0013: Chương trình trò chuyện cho phép ghi đè tệp qua yêu cầu smiley tùy chỉnh.
  • CVE-2009-4449: Bulletin board cho phép kẻ tấn công xác định sự tồn tại của tệp.
  • CVE-2009-4581: Chương trình PHP cho phép thực thi mã tùy ý khi tên tệp chứa .. được truyền vào include.
  • CVE-2008-5748: Việc kiểm soát từ bên ngoài các giá trị ngôn ngữ và giao diện đã cho phép traversal.
  • CVE-2009-1936: Kiểm tra chuyển hướng của tệp thư viện vẫn cho phép thực thi khi tệp bị yêu cầu trực tiếp, dẫn đến remote file inclusion và traversal.
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 (12)

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