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
Improperlyhandled 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
Common Consequences
Scope
Effect
Access Control
Technical Impact: Bypass protection
mechanism
Demonstrative Examples
Example 1
In the following example, an XSS neutralization method replaces
script tags in user supplied input with a safe equivalent:
(Bad Code)
Example
Language: Java
public String preventXSS(String input, String mask) {
return input.replaceAll("script", mask);
}
The code only works when the "script" tag is in all lower-case, forming an incomplete blacklist (CWE-184). Equivalent tags such as "SCRIPT" or "ScRiPt" will not be neutralized by this method, allowing an XSS attack.
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.
Server allows remote attackers to obtain source
code of CGI scripts via URLs that contain MS-DOS conventions such as (1)
upper case letters or (2) 8.3 file names.
Task Manager does not allow local users to end
processes with uppercase letters named (1) winlogon.exe, (2) csrss.exe, (3)
smss.exe and (4) services.exe via the Process tab which could allow local
users to install Trojan horses that cannot be
stopped.
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".
File extension check in forum software only
verifies extensions that contain all lowercase letters, which allows remote
attackers to upload arbitrary files via file extensions that include
uppercase letters.
Web server restricts access to files in a case
sensitive manner, but the filesystem accesses files in a case insensitive
manner, which allows remote attackers to read privileged files using
alternate capitalization.
Chain: uppercase file extensions causes web server
to return script source code instead of executing the
script.
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.
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)
Description
