Path Traversal: '..\filedir'
Weakness ID: 28 (Weakness Variant)Status: Incomplete
+ Description

Description Summary

The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly sanitize "..\" sequences that can resolve to a location that is outside of that directory.

Extended Description

This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory.

The '..\' manipulation is the canonical manipulation for operating systems that use "\" as directory separators, such as Windows. However, it is also useful for bypassing path traversal protection schemes that only assume that the "/" separator is valid.

+ Time of Introduction
  • Implementation
+ Applicable Platforms



Operating Systems


+ Observed Examples
CVE-2002-0661"\" not in blacklist for web server, allowing path traversal attacks when the server is run in Windows and other OSes.
CVE-2002-0946Arbitrary files may be read files via ..\ (dot dot) sequences in an HTTP request.
+ Potential Mitigations

Assume all input is malicious. Attackers can insert paths into input vectors and traverse the file system. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. Warning: if you attempt to cleanse your data, then do so that the end result is not in the form that can be dangerous. A sanitizing mechanism can remove characters such as '.' and ';' which may be required for some exploits. An attacker can try to fool the sanitizing mechanism into "cleaning" data into a dangerous form. Suppose the attacker injects a '.' inside a filename (e.g. "sensi.tiveFile") and the sanitizing mechanism removes the character resulting in the valid filename, "sensitiveFile". If the input data are now assumed to be safe, then the file may be compromised. See CWE-182 (Collapse of Data Into Unsafe Value).

Phase: Architecture and Design

Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data to be displayed or stored. Use an "accept known good" validation strategy. Input (specifically, unexpected CRLFs) that is not appropriate should not be processed into HTTP headers.

Use and specify a strong input/output encoding (such as ISO 8859-1 or UTF 8).

Do not rely exclusively on blacklist validation to detect malicious input or to encode output. There are too many variants to encode a character; you're likely to miss some variants.

Inputs should be decoded and canonicalized to the application's current internal representation before being validated. Make sure that your application does not decode the same input twice. Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base23Relative Path Traversal
Development Concepts (primary)699
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVER'..\filename' ('dot dot backslash')
+ Content History
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential Mitigations, Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy Mappings
2008-10-14CWE Content TeamMITREInternal
updated Applicable Platforms, Description, Name
2008-11-24CWE Content TeamMITREInternal
updated Observed Examples
2009-07-27CWE Content TeamMITREInternal
updated Potential Mitigations
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Dot Dot Backslash - '..\filename'
2008-10-14Path Traversal: '..\filename'