Path Traversal: '/absolute/pathname/here'
Weakness ID: 37 (Weakness Variant)Status: Draft
+ Description

Description Summary

A software system that accepts input in the form of a slash absolute path ('/absolute/pathname/here') without appropriate validation can allow an attacker to traverse the file system to unintended locations or access arbitrary files.
+ Time of Introduction
  • Implementation
+ Applicable Platforms



+ Observed Examples
CVE-2002-1345Multiple FTP clients write arbitrary files via absolute paths in server responses
CVE-2001-1269ZIP file extractor allows full path
CVE-2002-1818Path traversal using absolute pathname
CVE-2002-1913Path traversal using absolute pathname
CVE-2005-2147Path traversal using absolute pathname
CVE-2000-0614Arbitrary files may be overwritten via compressed attachments that specify absolute path names for the decompressed output.
+ 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 Base36Absolute Path Traversal
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness VariantWeakness Variant160Improper Sanitization of Leading Special Elements
Research Concepts1000
ChildOfCategoryCategory743CERT C Secure Coding Section 09 - Input Output (FIO)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingFIO05-CIdentify files using multiple file attributes
+ 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-11-24CWE Content TeamMITREInternal
updated Observed Examples, Relationships, Taxonomy Mappings
2009-07-27CWE Content TeamMITREInternal
updated Potential Mitigations
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Issue - Slash Absolute Path - /absolute/pathname/here