CWE

Common Weakness Enumeration

A Community-Developed Dictionary of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors Common Weakness Scoring System
Common Weakness Risk Analysis Framework
Home > CWE List > CWE- Individual Dictionary Definition (2.7)  

Presentation Filter:

CWE-182: Collapse of Data into Unsafe Value

 
Collapse of Data into Unsafe Value
Weakness ID: 182 (Weakness Base)Status: Draft
+ Description

Description Summary

The software filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect

Technical Impact: Bypass protection mechanism

+ Observed Examples
ReferenceDescription
"/.////" in pathname collapses to absolute path.
"/.//..//////././" is collapsed into "/.././" after ".." and "//" sequences are removed.
".../...//" collapsed to "..." due to removal of "./" in web server.
chain: HTTP server protects against ".." but allows "." variants such as "////./../.../". If the server removes "/.." sequences, the result would collapse into an unsafe value "////../" (CWE-182).
MFV. Regular expression intended to protect against directory traversal reduces ".../...//" to "../".
XSS protection mechanism strips a <script> sequence that is nested in another <script> sequence.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist 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 (i.e., do not rely on a blacklist). A blacklist 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, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: Implementation

Strategy: Input Validation

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 whitelist validation schemes by introducing dangerous inputs after they have been checked.

Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function).

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class693Protection Mechanism Failure
Research Concepts (primary)1000
ChildOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory845CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory896SFP Cluster: Tainted Input
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness VariantWeakness Variant33Path Traversal: '....' (Multiple Dot)
Research Concepts1000
CanPrecedeWeakness VariantWeakness Variant34Path Traversal: '....//'
Research Concepts1000
CanPrecedeWeakness VariantWeakness Variant35Path Traversal: '.../...//'
Research Concepts1000
CanFollowWeakness ClassWeakness Class185Incorrect Regular Expression
Research Concepts1000
+ Relationship Notes

Overlaps regular expressions, although an implementation might not necessarily use regexp's.

+ Relevant Properties
  • Trustability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERCollapse of Data into Unsafe Value
CERT Java Secure CodingIDS11-JEliminate noncharacter code points before validation
+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Character Stripping Vulnerabilities", Page 437.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Externally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01CigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08MITREInternal
updated Description, Relationships, Relationship_Notes, Relevant_Properties, Taxonomy_Mappings
2008-11-24MITREInternal
updated Observed_Examples
2009-03-10MITREInternal
updated Relationships
2009-07-27MITREInternal
updated Potential_Mitigations
2010-06-21MITREInternal
updated Description, Observed_Examples
2010-12-13MITREInternal
updated Relationships
2011-03-29MITREInternal
updated Potential_Mitigations
2011-06-01MITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11MITREInternal
updated References, Relationships, Taxonomy_Mappings
2012-10-30MITREInternal
updated Potential_Mitigations
Page Last Updated: June 23, 2014