The software does not properly account for differences in case
sensitivity when accessing or determining the properties of a resource, leading
to inconsistent results.
Extended Description
Improperly handled case sensitive data can lead to several possible
consequences, including:
case-insensitive passwords reducing the size of the key space, making
brute force attacks easier
bypassing filters or access controls using alternate names
multiple interpretation errors using alternate names.
Time of Introduction
Implementation
Applicable Platforms
Languages
All
Demonstrative Examples
Example 1
In the following example, an XSS sanitization routine only checks
for the lower-case "script" string, which can be easily defeated using tags
such as SCRIPT or ScRiPt.
(Bad Code)
Java
public String sanitize(String input, String mask) {
The server is case sensitive, so filetype handlers
treat .jsp and .JSP as different extensions. JSP source code may be read
because .JSP defaults to the filetype "text".
The server is case sensitive, so filetype handlers
treat .jsp and .JSP as different extensions. JSP source code may be read
because .JSP defaults to the filetype "text".
A URL that contains some characters whose case is
not matched by the server's filters may bypass access restrictions because
the case-insensitive file system will then handle the request after it
bypasses the case sensitive filter.
chain: Code was ported from a case-sensitive Unix
platform to a case-insensitive Windows platform where filetype handlers
treat .jsp and .JSP as different extensions. JSP source code may be read
because .JSP defaults to the filetype "text".
Chain: uppercase file extensions causes web server
to return script source code instead of executing the
script.
Potential Mitigations
Phase
Description
Avoid making decisions based on names of resources (e.g. files) if
those resources can have alternate names.
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.
Use and specify a strong 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.
These are probably under-studied in Windows and Mac environments, where
file names are case-insensitive and thus are subject to equivalence
manipulations involving case.
Affected Resources
File/Directory
Functional Areas
File Processing, Credentials
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
PLOVER
Case Sensitivity (lowercase, uppercase, mixed
case)
Content History
Submissions
Submission Date
Submitter
Organization
Source
PLOVER
Externally Mined
Modifications
Modification Date
Modifier
Organization
Source
2008-07-01
Sean Eidemiller
Cigital
External
added/updated demonstrative
examples
2008-07-01
Eric Dalci
Cigital
External
updated Potential Mitigations,
Time of Introduction
2008-09-08
CWE Content Team
MITRE
Internal
updated Description, Relationships, Observed Example,
Taxonomy Mappings
Description
