CWE-35: Path Traversal: '.../...//'
Official CWE-35 CWE context with Glexia analysis, remediation guidance, related CVEs, and ATT&CK context.
Glexia's Take
CWE-35: Path Traversal: '.../...//'
Path Traversal: '.../...//' represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Confidentiality,Integrity: Read Files or Directories,Modify Files or Directories,Bypass Protection Mechanism: Not properly neutralizing '.../...//' (doubled triple dot slash) allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.
Developer Pattern
CWE-35 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Confidence
high confidence from CWE-35, 4.20.
Official CWE Definition
CWE-35: Path Traversal: '.../...//'
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '.../...//' (doubled triple dot slash) sequences that can resolve to a location that is outside of that directory.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- Suppose the product serves files from a specific "public" directory -- /home/product/public/ -- and has an algorithm that attempts to protect against common path traversal attacks. The algorithm works by sequentially scanning through a requested filename and removes each occurrence of "../" that it encounters, then appending the filename to the public directory. If an attacker provides this filename:,then the code would correctly remove the "../" resulting in the name:,This request would fail, because secret.dat is not in /home/product/public/secret.dat.,The attacker could attempt to bypass this protection mechanism using this string:,The algorithm would remove the first occurrence of "../" to produce:,The algorithm would then find and remove the second (and final) "../" sequence, producing:,At this point, the algorithm stops because it removed all "../" that appeared in the original string, but the algorithm has collapsed the original input into an unsafe value (CWE-182) that is still subject to path traversal.,The end result is:,Which the OS resolves to /home/product/secret.dat, a file that is outside the public directory.
Remediation
- Implementation: [object Object]
- Implementation: Inputs 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.
Detection
- Automated Static Analysis: 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.)
Mappings
Related CVEs, CWEs, and ATT&CK context
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.