CWE nodes in this view (graph) are associated with the OWASP Top Ten, as released in 2004, and as required for compliance with PCI DSS version 1.1.
View Metrics
CWEs in this view
Total CWEs
Total
127
out of
920
Views
0
out of
29
Categories
15
out of
177
Weaknesses
111
out of
705
Compound_Elements
1
out of
9
View Audience
Stakeholder
Description
Developers
This view outlines the most important issues as identified by the
OWASP Top Ten (2004 version), providing a good starting point for web
application developers who want to code more securely, as well as
complying with PCI DSS 1.1.
Software_Customers
This view outlines the most important issues as identified by the
OWASP Top Ten, providing customers with a way of asking their software
developers to follow minimum expectations for secure code, in compliance
with PCI-DSS 1.1.
Educators
Since the OWASP Top Ten covers the most frequently encountered issues, this view can be used by educators as training material for students. However, the 2007 version (CWE-629) might be more appropriate.
CWE relationships for this view were obtained by examining the OWASP document and mapping to any items that were specifically mentioned within the text of a category. As a result, this mapping is not complete with respect to all of CWE. In addition, some concepts were mentioned in multiple Top Ten items, which caused them to be mapped to multiple CWE categories. For example, SQL injection is mentioned in both A1 (CWE-722) and A6 (CWE-727) categories.
Some parts of CWE are not fully fleshed out in terms of weaknesses. When
these areas were mentioned in the Top Ten, category nodes were mapped,
although general mapping practice would usually favor mapping only to
weaknesses.
ASP.NET Misconfiguration: Use of Identity Impersonation
Definition in a New Window
Weakness ID: 556 (Weakness Variant)
Status: Incomplete
Description
Description Summary
Configuring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges.
Extended Description
The use of impersonated credentials allows an ASP.NET application to run with either the privileges of the client on whose behalf it is executing or with arbitrary privileges granted in its configuration.
Time of Introduction
Implementation
Operation
Common Consequences
Scope
Effect
Access Control
Technical Impact: Gain privileges / assume
identity
Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.
Extended Description
This situation is amplified if the software allows malicious users or attackers to consume more resources than their access level permits. Exploiting such a weakness can lead to asymmetric resource consumption, aiding in amplification attacks against the system or the network.
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
Time of Introduction
Architecture and Design
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 "authenticated" cookie is used to
determine whether or not a user should be granted access to a system. Of
course, modifying the value of a cookie on the client-side is trivial, but
many developers assume that cookies are essentially immutable.
(Bad Code)
Example
Language: Java
boolean authenticated = new
Boolean(getCookieValue("authenticated")).booleanValue();
[REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Untrustworthy Credentials", Page
37.. 1st Edition. Addison Wesley. 2006.
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
Extended Description
Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user related record stored in the system and would be used to lookup that record for presentation to the user. It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system. One manifestation of this weakness would be if a system used sequential or otherwise easily guessable session ids that would allow one user to easily switch to another user's session and read/modify their data.
Alternate Terms
Insecure Direct Object Reference:
The "Insecure Direct Object Reference" term, as described in the OWASP Top Ten, is broader than this CWE because it also covers path traversal (CWE-22). Within the context of vulnerability theory, there is a similarity between the OWASP concept and CWE-706: Use of Incorrectly-Resolved Name or Reference.
Horizontal Authorization:
"Horizontal Authorization" is used to describe situations in which two
users have the same privilege level, but must be prevented from
accessing each other's resources. This is fairly common when using
key-based access to resources in a multi-user context.
Time of Introduction
Architecture and Design
Applicable Platforms
Languages
Language-independent
Common Consequences
Scope
Effect
Access Control
Technical Impact: Bypass protection
mechanism
Access control checks for specific user data or functionality can be
bypassed.
Access Control
Technical Impact: Gain privileges / assume
identity
Horizontal escalation of privilege is possible (one user can
view/modify information of another user).
Access Control
Technical Impact: Gain privileges / assume
identity
Vertical escalation of privilege is possible if the user-controlled
key is actually a flag that indicates administrator status, allowing the
attacker to gain administrative access.
Likelihood of Exploit
High
Enabling Factors for Exploitation
The key used internally in the system to identify the user record can be
externally controlled. For example attackers can look at places where user
specific data is retrieved (e.g. search screens) and determine whether the
key for the item being looked up is controllable externally. The key may be
a hidden field in the HTML form field, might be passed as a URL parameter or
as an unencrypted cookie variable, then in each of these cases it will be
possible to tamper with the key value.
Potential Mitigations
Phase: Architecture and Design
For each and every data access, ensure that the user has sufficient
privilege to access the record that is being requested.
Phases: Architecture and Design; Implementation
Make sure that the key that is used in the lookup of a specific user's
record is not controllable externally by the user or that any tampering
can be detected.
Phase: Architecture and Design
Use encryption in order to make it more difficult to guess other
legitimate values of the key or associate a digital signature with the
key so that the server can verify that there has been no tampering.
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Definition in a New Window
Weakness ID: 120 (Weakness Base)
Status: Incomplete
Description
Description Summary
The program copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
Extended Description
A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold, or when a program attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the "classic" case in which the program copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.
Alternate Terms
buffer overrun:
Some prominent vendors and researchers use the term "buffer overrun,"
but most people use "buffer overflow."
Unbounded Transfer
Terminology Notes
Many issues that are now called "buffer overflows" are substantively
different than the "classic" overflow, including entirely different bug
types that rely on overflow exploit techniques, such as integer signedness
errors, integer overflows, and format string bugs. This imprecise
terminology can make it difficult to determine which variant is being
reported.
Time of Introduction
Implementation
Applicable Platforms
Languages
C
C++
Assembly
Common Consequences
Scope
Effect
Integrity
Confidentiality
Availability
Technical Impact: Execute unauthorized code or
commands
Buffer overflows often can be used to execute arbitrary code, which is
usually outside the scope of a program's implicit security policy. This
can often be used to subvert any other security service.
Buffer overflows generally lead to crashes. Other attacks leading to
lack of availability are possible, including putting the program into an
infinite loop.
Likelihood of Exploit
High to Very High
Detection Methods
Automated Static Analysis
This weakness can often be detected using automated static analysis
tools. Many modern tools use data flow analysis or constraint-based
techniques to minimize the number of false positives.
Automated static analysis generally does not account for environmental
considerations when reporting out-of-bounds memory operations. This can
make it difficult for users to determine which warnings should be
investigated first. For example, an analysis tool might report buffer
overflows that originate from command line arguments in a program that
is not expected to run with setuid or other special privileges.
Effectiveness: High
Detection techniques for buffer-related errors are more mature than
for most other weakness types.
Automated Dynamic Analysis
This weakness can be detected using dynamic tools and techniques that
interact with the software using large test suites with many diverse
inputs, such as fuzz testing (fuzzing), robustness testing, and fault
injection. The software's operation may slow down, but it should not
become unstable, crash, or generate incorrect results.
Manual Analysis
Manual analysis can be useful for finding this weakness, but it might
not achieve desired code coverage within limited time constraints. This
becomes difficult for weaknesses that must be considered for all inputs,
since the attack surface can be too large.
Demonstrative Examples
Example 1
The following code asks the user to enter their last name and then
attempts to store the value entered in the last_name array.
(Bad Code)
Example
Language: C
char last_name[20];
printf ("Enter your last name: ");
scanf ("%s", last_name);
The problem with the code above is that it does not restrict or limit
the size of the name entered by the user. If the user enters
"Very_very_long_last_name" which is 24 characters long, then a buffer
overflow will occur since the array can only hold 20 characters total.
Example 2
The following code attempts to create a local copy of a buffer to
perform some manipulations to the data.
(Bad Code)
Example
Language: C
void manipulate_string(char* string){
char buf[24];
strcpy(buf, string);
...
}
However, the programmer does not ensure that the size of the data
pointed to by string will fit in the local buffer and blindly copies the
data with the potentially dangerous strcpy() function. This may result
in a buffer overflow condition if an attacker can influence the contents
of the string parameter.
Example 3
The excerpt below calls the gets() function in C, which is
inherently unsafe.
(Bad Code)
Example
Language: C
char buf[24];
printf("Please enter your name and press
<Enter>\n");
gets(buf);
...
}
However, the programmer uses the function gets() which is inherently
unsafe because it blindly copies all input from STDIN to the buffer
without restricting how much is copied. This allows the user to provide
a string that is larger than the buffer size, resulting in an overflow
condition.
Example 4
In the following example, a server accepts connections from a client
and processes the client request. After accepting a client connection, the
program will obtain client information using the gethostbyaddr method, copy
the hostname of the client that connected to a local variable and output the
hostname of the client to a log file.
(Bad Code)
Example Languages: C and C++
...
struct hostent *clienthp;
char hostname[MAX_LEN];
// create server socket, bind to server address and listen on
socket
...
// accept client connections and process requests
int count = 0;
for (count = 0; count < MAX_CONNECTIONS; count++)
{
int clientlen = sizeof(struct sockaddr_in);
int clientsocket = accept(serversocket, (struct sockaddr
*)&clientaddr, &clientlen);
logOutput("Accepted client connection from host ",
hostname);
// process client request
...
close(clientsocket);
}
}
close(serversocket);
...
However, the hostname of the client that connected may be longer than
the allocated size for the local hostname variable. This will result in
a buffer overflow when copying the client hostname to the local variable
using the strcpy method.
By replacing a valid cookie value with an
extremely long string of characters, an attacker may overflow the
application's buffers.
Potential Mitigations
Phase: Requirements
Strategy: Language Selection
Use a language that does not allow this weakness to occur or provides
constructs that make this weakness easier to avoid.
For example, many languages that perform their own memory management,
such as Java and Perl, are not subject to buffer overflows. Other
languages, such as Ada and C#, typically provide overflow protection,
but the protection can be disabled by the programmer.
Be wary that a language's interface to native code may still be
subject to overflows, even if the language itself is theoretically safe.
Phase: Architecture and Design
Strategy: Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to
occur or provides constructs that make this weakness easier to
avoid.
Examples include the Safe C String Library (SafeStr) by Messier and Viega [R.120.4], and the Strsafe.h library from Microsoft [R.120.3]. These libraries provide safer versions of overflow-prone string-handling functions.
This is not a complete solution, since many buffer overflows are not
related to strings.
Phase: Build and Compilation
Strategy: Compilation or Build Hardening
Run or compile the software using features or extensions that
automatically provide a protection mechanism that mitigates or
eliminates buffer overflows.
For example, certain compilers and extensions provide automatic buffer
overflow detection mechanisms that are built into the compiled code.
Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat
FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.
Effectiveness: Defense in Depth
This is not necessarily a complete solution, since these mechanisms
can only detect certain types of overflows. In addition, an attack could
still cause a denial of service, since the typical response is to exit
the application.
Phase: Implementation
Consider adhering to the following rules when allocating and managing
an application's memory:
Double check that your buffer is as large as you specify.
When using functions that accept a number of bytes to copy, such
as strncpy(), be aware that if the destination buffer size is equal
to the source buffer size, it may not NULL-terminate the
string.
Check buffer boundaries if accessing the buffer in a loop and make
sure you are not in danger of writing past the allocated
space.
If necessary, truncate all input strings to a reasonable length
before passing them to the copy and concatenation functions.
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: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Phase: Operation
Strategy: Environment Hardening
Use a feature like Address Space Layout Randomization (ASLR) [R.120.5] [R.120.7].
Effectiveness: Defense in Depth
This is not a complete solution. However, it forces the attacker to
guess an unknown value that changes every program execution. In
addition, an attack could still cause a denial of service, since the
typical response is to exit the application.
Phase: Operation
Strategy: Environment Hardening
Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [R.120.7] [R.120.9].
Effectiveness: Defense in Depth
This is not a complete solution, since buffer overflows could be used
to overwrite nearby variables to modify the software's state in
dangerous ways. In addition, it cannot be used in cases in which
self-modifying code is required. Finally, an attack could still cause a
denial of service, since the typical response is to exit the
application.
Phases: Build and Compilation; Operation
Most mitigating technologies at the compiler or OS level to date
address only a subset of buffer overflow problems and rarely provide
complete protection against even that subset. It is good practice to
implement strategies to increase the workload of an attacker, such as
leaving the attacker to guess an unknown value that changes every
program execution.
Phase: Implementation
Replace unbounded copy functions with analogous functions that support
length arguments, such as strcpy with strncpy. Create these if they are
not available.
Effectiveness: Moderate
This approach is still susceptible to calculation errors, including issues such as off-by-one errors (CWE-193) and incorrectly calculating buffer lengths (CWE-131).
Phase: Architecture and Design
Strategy: Enforcement by Conversion
When the set of acceptable objects, such as filenames or URLs, is
limited or known, create a mapping from a set of fixed input values
(such as numeric IDs) to the actual filenames or URLs, and reject all
other inputs.
Phases: Architecture and Design; Operation
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.120.10]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Phases: Architecture and Design; Operation
Strategy: Sandbox or Jail
Run the code in a "jail" or similar sandbox environment that enforces
strict boundaries between the process and the operating system. This may
effectively restrict which files can be accessed in a particular
directory or which commands can be executed by the software.
OS-level examples include the Unix chroot jail, AppArmor, and SELinux.
In general, managed code may provide some protection. For example,
java.io.FilePermission in the Java SecurityManager allows the software
to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to
the operating system; the rest of the application may still be subject
to compromise.
Be careful to avoid CWE-243 and other weaknesses related to jails.
Effectiveness: Limited
The effectiveness of this mitigation depends on the prevention
capabilities of the specific sandbox or jail being used and might only
help to reduce the scope of an attack, such as restricting the attacker
to certain system calls or limiting the portion of the file system that
can be accessed.
Weakness Ordinalities
Ordinality
Description
Resultant
(where
the weakness is typically related to the presence of some other
weaknesses)
Primary
(where
the weakness exists independent of other weaknesses)
At the code level, stack-based and heap-based overflows do not differ
significantly, so there usually is not a need to distinguish them. From the
attacker perspective, they can be quite different, since different
techniques are required to exploit them.
Affected Resources
Memory
Functional Areas
Memory Management
Causal Nature
Explicit
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
PLOVER
Unbounded Transfer ('classic overflow')
7 Pernicious Kingdoms
Buffer Overflow
CLASP
Buffer overflow
OWASP Top Ten 2004
A1
CWE_More_Specific
Unvalidated Input
OWASP Top Ten 2004
A5
CWE_More_Specific
Buffer Overflows
CERT C Secure Coding
STR35-C
Do not copy data from an unbounded source to a fixed-length
array
WASC
7
Buffer Overflow
CERT C++ Secure Coding
STR35-CPP
Do not copy data from an unbounded source to a fixed-length
array
A weakness where the code path includes a Buffer Write Operation such
that:
1. the expected size of the buffer is greater than the actual size of
the buffer where expected size is equal to the sum of the size of the
data item and the position in the buffer
Where Buffer Write Operation is a statement that writes a data item of a
certain size into a buffer at a certain position and at a certain
index
References
[R.120.1] [REF-11] M. Howard and
D. LeBlanc. "Writing Secure Code". Chapter 5, "Public Enemy #1: The Buffer Overrun" Page
127. 2nd Edition. Microsoft. 2002.
[R.120.2] [REF-17] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[R.120.11] [REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Nonexecutable Stack", Page
76.. 1st Edition. Addison Wesley. 2006.
[R.120.12] [REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page
189.. 1st Edition. Addison Wesley. 2006.
[R.120.13] [REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "C String Handling", Page 388.. 1st Edition. Addison Wesley. 2006.
The software is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
Extended Description
When the server relies on protection mechanisms placed on the client side, an attacker can modify the client-side behavior to bypass the protection mechanisms resulting in potentially unexpected interactions between the client and server. The consequences will vary, depending on what the mechanisms are trying to protect.
Client-side validation checks can be easily bypassed, allowing
malformed or unexpected input to pass into the application, potentially
as trusted data. This may lead to unexpected states, behaviors and
possibly a resulting crash.
Access Control
Technical Impact: Bypass protection
mechanism; Gain privileges / assume
identity
Client-side checks for authentication can be easily bypassed, allowing
clients to escalate their access levels and perform unintended
actions.
Likelihood of Exploit
Medium
Enabling Factors for Exploitation
Consider a product that consists of two or more processes or nodes that
must interact closely, such as a client/server model. If the product uses
protection schemes in the client in order to defend from attacks against the
server, and the server does not use the same schemes, then an attacker could
modify the client in a way that bypasses those schemes. This is a
fundamental design flaw that is primary to many weaknesses.
Demonstrative Examples
Example 1
This example contains client-side code that checks if the user
authenticated successfully before sending a command. The server-side code
performs the authentication in one step, and executes the command in a
separate step.
CLIENT-SIDE (client.pl)
(Good Code)
Example
Language: Perl
$server = "server.example.com";
$username = AskForUserName();
$password = AskForPassword();
$address = AskForAddress();
$sock = OpenSocket($server, 1234);
writeSocket($sock, "AUTH $username $password\n");
$resp = readSocket($sock);
if ($resp eq "success") {
# username/pass is valid, go ahead and update the
info!
writeSocket($sock, "FAILURE -- address is
malformed\n");
}
}
The server accepts 2 commands, "AUTH" which authenticates the user,
and "CHANGE-ADDRESS" which updates the address field for the username.
The client performs the authentication and only sends a CHANGE-ADDRESS
for that user if the authentication succeeds. Because the client has
already performed the authentication, the server assumes that the
username in the CHANGE-ADDRESS is the same as the authenticated user. An
attacker could modify the client by removing the code that sends the
"AUTH" command and simply executing the CHANGE-ADDRESS.
client allows server to modify client's
configuration and overwrite arbitrary files.
Potential Mitigations
Phase: Architecture and Design
For any security checks that are performed on the client side, ensure
that these checks are duplicated on the server side. Attackers can
bypass the client-side checks by modifying values after the checks have
been performed, or by changing the client to remove the client-side
checks entirely. Then, these modified values would be submitted to the
server.
Even though client-side checks provide minimal benefits with respect
to server-side security, they are still useful. First, they can support
intrusion detection. If the server receives input that should have been
rejected by the client, then it may be an indication of an attack.
Second, client-side error-checking can provide helpful feedback to the
user about the expectations for valid input. Third, there may be a
reduction in server-side processing time for accidental input errors,
although this is typically a small savings.
Phase: Architecture and Design
If some degree of trust is required between the two entities, then use
integrity checking and strong authentication to ensure that the inputs
are coming from a trusted source. Design the product so that this trust
is managed in a centralized fashion, especially if there are complex or
numerous communication channels, in order to reduce the risks that the
implementer will mistakenly omit a check in a single code path.
Phase: Testing
Use dynamic tools and techniques that interact with the software using
large test suites with many diverse inputs, such as fuzz testing
(fuzzing), robustness testing, and fault injection. The software's
operation may slow down, but it should not become unstable, crash, or
generate incorrect results.
Phase: Testing
Use tools and techniques that require manual (human) analysis, such as
penetration testing, threat modeling, and interactive tools that allow
the tester to record and modify an active session. These may be more
effective than strictly automated techniques. This is especially the
case with weaknesses that are related to design and business
rules.
Weakness Ordinalities
Ordinality
Description
Primary
(where
the weakness exists independent of other weaknesses)
Server-side enforcement of client-side security is conceptually likely to
occur, but some architectures might have these strong dependencies as part
of legitimate behavior, such as thin clients.
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).
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).
Overlaps regular expressions, although an implementation might not
necessarily use regexp's.
Relevant Properties
Trustability
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
PLOVER
Collapse of Data into Unsafe Value
CERT Java Secure Coding
IDS11-J
Eliminate 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.
Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal."
Extended Description
This compiler optimization error occurs when:
1. Secret data are stored in memory.
2. The secret data are scrubbed from memory by overwriting its contents.
3. The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently.
This weakness will allow data that has not been cleared from memory to
be read. If this data contains sensitive password information, then an
attacker can read the password and use the information to bypass
protection mechanisms.
Detection Methods
Black Box
This specific weakness is impossible to detect using black box
methods. While an analyst could examine memory to see that it has not
been scrubbed, an analysis of the executable would not be successful.
This is because the compiler has already removed the relevant code. Only
the source code shows whether the programmer intended to clear the
memory or not, so this weakness is indistinguishable from others.
White Box
This weakness is only detectable using white box methods (see black
box detection factor). Careful analysis is required to determine if the
code is likely to be removed by the compiler.
Demonstrative Examples
Example 1
The following code reads a password from the user, uses the password
to connect to a back-end mainframe and then attempts to scrub the password
from memory using memset().
(Bad Code)
Example
Language: C
void GetData(char *MFAddr) {
char pwd[64];
if (GetPasswordFromUser(pwd, sizeof(pwd))) {
if (ConnectToMainframe(MFAddr, pwd)) {
// Interaction with mainframe
}
}
memset(pwd, 0, sizeof(pwd));
}
The code in the example will behave correctly if it is executed
verbatim, but if the code is compiled using an optimizing compiler, such
as Microsoft Visual C++ .NET or GCC 3.x, then the call to memset() will
be removed as a dead store because the buffer pwd is not used after its
value is overwritten [18]. Because the buffer pwd contains a sensitive
value, the application may be vulnerable to attack if the data are left
memory resident. If attackers are able to access the correct region of
memory, they may use the recovered password to gain control of the
system.
It is common practice to overwrite sensitive data manipulated in
memory, such as passwords or cryptographic keys, in order to prevent
attackers from learning system secrets. However, with the advent of
optimizing compilers, programs do not always behave as their source code
alone would suggest. In the example, the compiler interprets the call to
memset() as dead code because the memory being written to is not
subsequently used, despite the fact that there is clearly a security
motivation for the operation to occur. The problem here is that many
compilers, and in fact many programming languages, do not take this and
other security concerns into consideration in their efforts to improve
efficiency.
Attackers typically exploit this type of vulnerability by using a
core dump or runtime mechanism to access the memory used by a particular
application and recover the secret information. Once an attacker has
access to the secret information, it is relatively straightforward to
further exploit the system and possibly compromise other resources with
which the application interacts.
Potential Mitigations
Phase: Implementation
Store the sensitive data in a "volatile" memory location if
available.
Phase: Build and Compilation
If possible, configure your compiler so that it does not remove dead
stores.
Phase: Architecture and Design
Where possible, encrypt sensitive data that are used by a software
system.
The software detects a specific error, but takes no actions to handle the error.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Integrity
Other
Technical Impact: Varies by context; Unexpected state; Alter execution
logic
An attacker could utilize an ignored error condition to place the
system in an unexpected state that could lead to the execution of
unintended logic and could cause other unintended behavior.
Likelihood of Exploit
Medium
Demonstrative Examples
Example 1
The following example attempts to allocate memory for a character.
After the call to malloc, an if statement is used to check whether the
malloc function failed.
(Bad Code)
Example
Language: C
foo=malloc(sizeof(char)); //the next line checks to see if malloc
failed
if (foo==NULL) {
//We do nothing so we just ignore the error.
}
The conditional successfully detects a NULL return value from malloc
indicating a failure, however it does not do anything to handle the
problem. Unhandled errors may have unexpected results and may cause the
program to crash or terminate.
Instead, the if block should contain statements that either attempt to
fix the problem or notify the user that an error has occurred and
continue processing or perform some cleanup and gracefully terminate the
program. The following example notifies the user that the malloc
function did not allocate the required memory resources and returns an
error code.
(Good Code)
Example
Language: C
foo=malloc(sizeof(char)); //the next line checks to see if malloc
failed
if (foo==NULL) {
printf("Malloc failed to allocate memory resources");
return -1;
}
Example 2
In the following C++ example the method readFile() will read the
file whose name is provided in the input parameter and will return the
contents of the file in char string. The method calls open() and read() may
result in errors if the file does not exist or does not contain any data to
read. These errors will be thrown when the is_open() method and good()
method indicate errors opening or reading the file. However, these errors
are not handled within the catch statement. Catch statements that do not
perform any processing will have unexpected results. In this case an empty
char string will be returned, and the file will not be properly
closed.
(Bad Code)
Example
Language: C++
char* readfile (char *filename) {
try {
// open input file
ifstream infile;
infile.open(filename);
if (!infile.is_open()) {
throw "Unable to open file " + filename;
}
// get length of file
infile.seekg (0, ios::end);
int length = infile.tellg();
infile.seekg (0, ios::beg);
// allocate memory
char *buffer = new char [length];
// read data from file
infile.read (buffer,length);
if (!infile.good()) {
throw "Unable to read from file " + filename;
}
infile.close();
return buffer;
}
catch (...) {
/* bug: insert code to handle this later */
}
}
The catch statement should contain statements that either attempt to
fix the problem or notify the user that an error has occurred and
continue processing or perform some cleanup and gracefully terminate the
program. The following C++ example contains two catch statements. The
first of these will catch a specific error thrown within the try block,
and the second catch statement will catch all other errors from within
the catch block. Both catch statements will notify the user that an
error has occurred, close the file, and rethrow to the block that called
the readFile() method for further handling or possible termination of
the program.
(Good Code)
Example
Language: C++
char* readFile (char *filename) {
try {
// open input file
ifstream infile;
infile.open(filename);
if (!infile.is_open()) {
throw "Unable to open file " + filename;
}
// get length of file
infile.seekg (0, ios::end);
int length = infile.tellg();
infile.seekg (0, ios::beg);
// allocate memory
char *buffer = new char [length];
// read data from file
infile.read (buffer,length);
if (!infile.good()) {
throw "Unable to read from file " + filename;
}
infile.close();
return buffer;
}
catch (char *str) {
printf("Error: %s \n", str);
infile.close();
throw str;
}
catch (...) {
printf("Error occurred trying to read from file
\n");
infile.close();
throw;
}
}
Example 3
In the following Java example the method readFile will read the file
whose name is provided in the input parameter and will return the contents
of the file in a String object. The constructor of the FileReader object and
the read method call may throw exceptions and therefore must be within a
try/catch block. While the catch statement in this example will catch thrown
exceptions in order for the method to compile, no processing is performed to
handle the thrown exceptions. Catch statements that do not perform any
processing will have unexpected results. In this case, this will result in
the return of a null String.
(Bad Code)
Example
Language: Java
public String readFile(String filename) {
String retString = null;
try {
// initialize File and FileReader objects
File file = new File(filename);
FileReader fr = new FileReader(file);
// initialize character buffer
long fLen = file.length();
char[] cBuf = new char[(int) fLen];
// read data from file
int iRead = fr.read(cBuf, 0, (int) fLen);
// close file
fr.close();
retString = new String(cBuf);
} catch (Exception ex) {
/* do nothing, but catch so it'll compile... */
}
return retString;
}
The catch statement should contain statements that either attempt to
fix the problem, notify the user that an exception has been raised and
continue processing, or perform some cleanup and gracefully terminate
the program. The following Java example contains three catch statements.
The first of these will catch the FileNotFoundException that may be
thrown by the FileReader constructor called within the try/catch block.
The second catch statement will catch the IOException that may be thrown
by the read method called within the try/catch block. The third catch
statement will catch all other exceptions thrown within the try block.
For all catch statements the user is notified that the exception has
been thrown and the exception is rethrown to the block that called the
readFile() method for further processing or possible termination of the
program. Note that with Java it is usually good practice to use the
getMessage() method of the exception class to provide more information
to the user about the exception raised.
(Good Code)
Example
Language: Java
public String readFile(String filename) throws
FileNotFoundException, IOException, Exception {
System.err.println("Error: IOException reading the input
file.\n" + ex.getMessage() );
throw new IOException(ex);
} catch (Exception ex) {
System.err.println("Error: Exception reading the input
file.\n" + ex.getMessage() );
throw new Exception(ex);
}
return retString;
}
Potential Mitigations
Phase: Implementation
Properly handle each exception. This is the recommended solution.
Ensure that all exceptions are handled in such a way that you can be
sure of the state of your system at any given moment.
Phase: Implementation
If a function returns an error, it is important to either fix the
problem and try again, alert the user that an error has happened and let
the program continue, or alert the user and close and cleanup the
program.
Phase: Testing
Subject the software to extensive testing to discover some of the
possible instances of where/how errors or return values are not handled.
Consider testing techniques such as ad hoc, equivalence partitioning,
robustness and fault tolerance, mutation, and fuzzing.
[REF-17] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page
183. McGraw-Hill. 2010.
The web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files.
Extended Description
Web applications susceptible to direct request attacks often make the false assumption that such resources can only be reached through a given navigation path and so only apply authorization at certain points in the path.
Alternate Terms
forced browsing:
The "forced browsing" term could be misinterpreted to include
weaknesses such as CSRF or XSS, so its use is discouraged.
Time of Introduction
Architecture and Design
Implementation
Operation
Applicable Platforms
Languages
Language-independent
Common Consequences
Scope
Effect
Confidentiality
Integrity
Availability
Access Control
Technical Impact: Read application
data; Modify application
data; Execute unauthorized code or
commands; Gain privileges / assume
identity
Demonstrative Examples
Example 1
If forced browsing is possible, an attacker may be able to directly
access a sensitive page by entering a URL similar to the
following.
Overlaps Modification of Assumed-Immutable Data (MAID), authorization
errors, container errors; often primary to other weaknesses such as XSS and
SQL injection.
Theoretical Notes
"Forced browsing" is a step-based manipulation involving the omission of
one or more steps, whose order is assumed to be immutable. The application
does not verify that the first step was performed successfully before the
second step. The consequence is typically "authentication bypass" or "path
disclosure," although it can be primary to all kinds of weaknesses,
especially in languages such as PHP, which allow external modification of
assumed-immutable variables.
This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height.
Time of Introduction
Implementation
Common Consequences
Scope
Effect
Availability
Technical Impact: DoS: crash / exit /
restart
A Divide by Zero results in a crash.
Likelihood of Exploit
Medium
Demonstrative Examples
Example 1
The following Java example contains a function to compute an average
but does not validate that the input value used as the denominator is not
zero. This will create an exception for attempting to divide by zero. If
this error is not handled by Java exception handling, unexpected results can
occur.
(Bad Code)
Example
Language: Java
public int computeAverageResponseTime (int totalTime, int
numRequests) {
return totalTime / numRequests;
}
By validating the input value used as the denominator the following
code will ensure that a divide by zero error will not cause unexpected
results. The following Java code example will validate the input value,
output an error message, and throw an exception.
(Good Code)
public int computeAverageResponseTime (int totalTime, int
numRequests) throws ArithmeticException {
if (numRequests == 0) {
System.out.println("Division by zero attempted!");
throw ArithmeticException;
}
return totalTime / numRequests;
}
Example 2
The following C/C++ example contains a function that divides two
numeric values without verifying that the input value used as the
denominator is not zero. This will create an error for attempting to divide
by zero, if this error is not caught by the error handling capabilities of
the language, unexpected results can occur.
(Bad Code)
Example Languages: C and C++
double divide(double x, double y){
return x/y;
}
By validating the input value used as the denominator the following
code will ensure that a divide by zero error will not cause unexpected
results. If the method is called and a zero is passed as the second
argument a DivideByZero error will be thrown and should be caught by the
calling block with an output message indicating the error.
The following C# example contains a function that divides two
numeric values without verifying that the input value used as the
denominator is not zero. This will create an error for attempting to divide
by zero, if this error is not caught by the error handling capabilities of
the language, unexpected results can occur.
(Bad Code)
Example
Language: C#
int Division(int x, int y){
return (x / y);
}
The method can be modified to raise, catch and handle the
DivideByZeroException if the input value used as the denominator is
zero.
(Good Code)
int SafeDivision(int x, int y){
try{
return (x / y);
}
catch (System.DivideByZeroException dbz){
System.Console.WriteLine("Division by zero
attempted!");
This category includes weaknesses that occur when an application does not properly handle errors that occur during processing.
Extended Description
An attacker may discover this type of error, as forcing these errors can occur with a variety of corrupt input.
Common Consequences
Scope
Effect
Integrity
Confidentiality
Technical Impact: Read application
data; Modify files or
directories
Generally, the consequences of improper error handling are the
disclosure of the internal workings of the application to the attacker,
providing details to use in further attacks. Web applications that do
not properly handle error conditions frequently generate error messages
such as stack traces, detailed diagnostics, and other inner details of
the application.
Demonstrative Examples
Example 1
In the snippet below, an unchecked runtime exception thrown from
within the try block may cause the container to display its default error
page (which may contain a full stack trace, among other
things).
(Bad Code)
Example
Language: Java
Public void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
try {
...
}
catch (ApplicationSpecificException ase) {
logger.error("Caught: " + ase.toString());
}
}
Potential Mitigations
Use a standard exception handling mechanism to be sure that your
application properly handles all types of processing errors. All error
messages sent to the user should contain as little detail as necessary
to explain what happened.
If the error was caused by unexpected and likely malicious input, it
may be appropriate to send the user no error message other than a simple
"could not process the request" response.
The details of the error and its cause should be recorded in a
detailed diagnostic log for later analysis. Do not allow the application
to throw errors up to the application container, generally the web
application server.
Be sure that the container is properly configured to handle errors if
you choose to let any errors propagate up to it.
[REF-17] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page
183. McGraw-Hill. 2010.
Exposure of Access Control List Files to an Unauthorized Control Sphere
Definition in a New Window
Weakness ID: 529 (Weakness Variant)
Status: Incomplete
Description
Description Summary
The product stores access control list files in a directory or other container that is accessible to actors outside of the intended control sphere.
Extended Description
Exposure of these access control list files may give the attacker information about the configuration of the site or system. This information may then be used to bypass the intended security policy or identify trusted systems from which an attack can be launched.
Exposure of Backup File to an Unauthorized Control Sphere
Definition in a New Window
Weakness ID: 530 (Weakness Variant)
Status: Incomplete
Description
Description Summary
A backup file is stored in a directory that is accessible to actors outside of the intended control sphere.
Extended Description
Often, old files are renamed with an extension such as .~bk to distinguish them from production files. The source code for old files that have been renamed in this manner and left in the webroot can often be retrieved. This renaming may have been performed automatically by the web server, or manually by the administrator.
Time of Introduction
Implementation
Operation
Common Consequences
Scope
Effect
Confidentiality
Technical Impact: Read application
data
At a minimum, an attacker who retrieves this file would have all the
information contained in it, whether that be database calls, the format
of parameters accepted by the application, or simply information
regarding the architectural structure of your site.
Potential Mitigations
Phase: Policy
Recommendations include implementing a security policy within your
organization that prohibits backing up web application source code in
the webroot.
Exposure of CVS Repository to an Unauthorized Control Sphere
Definition in a New Window
Weakness ID: 527 (Weakness Variant)
Status: Incomplete
Description
Description Summary
The product stores a CVS repository in a directory or other container that is accessible to actors outside of the intended control sphere.
Extended Description
Information contained within a CVS subdirectory on a web server or other server could be recovered by an attacker and used for malicious purposes. This information may include usernames, filenames, path root, and IP addresses.
Time of Introduction
Operation
Common Consequences
Scope
Effect
Confidentiality
Technical Impact: Read application
data; Read files or
directories
Potential Mitigations
Phases: Operation; Distribution; System Configuration
Recommendations include removing any CVS directories and repositories
from the production server, disabling the use of remote CVS
repositories, and ensuring that the latest CVS patches and version
updates have been performed.
External Control of Assumed-Immutable Web Parameter
Definition in a New Window
Weakness ID: 472 (Weakness Base)
Status: Draft
Description
Description Summary
The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.
Extended Description
If a web product does not properly protect assumed-immutable values from modification in hidden form fields, parameters, cookies, or URLs, this can lead to modification of critical data. Web applications often mistakenly make the assumption that data passed to the client in hidden fields or cookies is not susceptible to tampering. Improper validation of data that are user-controllable can lead to the application processing incorrect, and often malicious, input.
For example, custom cookies commonly store session data or persistent data across sessions. This kind of session data is normally involved in security related decisions on the server side, such as user authentication and access control. Thus, the cookies might contain sensitive data such as user credentials and privileges. This is a dangerous practice, as it can often lead to improperreliance on the value of the client-provided cookie by the server side application.
Alternate Terms
Assumed-Immutable Parameter Tampering
Time of Introduction
Implementation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Integrity
Technical Impact: Modify application
data
Without appropriate protection mechanisms, the client can easily
tamper with cookies and similar web data. Reliance on the cookies
without detailed validation can lead to problems such as SQL injection.
If you use cookie values for security related decisions on the server
side, manipulating the cookies might lead to violations of security
policies such as authentication bypassing, user impersonation and
privilege escalation. In addition, storing sensitive data in the cookie
without appropriate protection can also lead to disclosure of sensitive
user data, especially data stored in persistent cookies.
Demonstrative Examples
Example 1
Here, a web application uses the value of a hidden form field
(accountID) without having done any input validation because it was assumed
to be immutable.
User user = getUserFromID(Long.parseLong(accountID));
Example 2
Hidden fields should not be trusted as secure parameters. An attacker
can intercept and alter hidden fields in a post to the server as easily
as user input fields. An attacker can simply parse the HTML for the
substring:
(Bad Code)
Example
Language: HTML
< input type "hidden"
or even just "hidden". Hidden field values displayed later in the
session, such as on the following page, can open a site up to
cross-site scripting attacks.
Modification of message number parameter allows
attackers to read other people's messages.
Potential Mitigations
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.
[REF-17] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 4: Use of Magic URLs, Predictable Cookies, and Hidden
Form Fields." Page 75. McGraw-Hill. 2010.
[REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "Embedding State in HTML and URLs", Page
1032.. 1st Edition. Addison Wesley. 2006.
The software allows user input to control or influence paths or file names that are used in filesystem operations.
Extended Description
This could allow an attacker to access or modify system files or other files that are critical to the application.
Path manipulation errors occur when the following two conditions are met:
1. An attacker can specify a path used in an operation on the filesystem.
2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.
For example, the program may give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker.
Time of Introduction
Architecture and Design
Implementation
Operation
Applicable Platforms
Languages
All
Operating Systems
UNIX: (Often)
Windows: (Often)
Mac OS: (Often)
Common Consequences
Scope
Effect
Integrity
Confidentiality
Technical Impact: Read files or
directories; Modify files or
directories
The application can operate on unexpected files. Confidentiality is
violated when the targeted filename is not directly readable by the
attacker.
Integrity
Confidentiality
Availability
Technical Impact: Modify files or
directories; Execute unauthorized code or
commands
The application can operate on unexpected files. This may violate
integrity if the filename is written to, or if the filename is for a
program or other form of executable code.
The application can operate on unexpected files. Availability can be
violated if the attacker specifies an unexpected file that the
application modifies. Availability can also be affected if the attacker
specifies a filename for a large file, or points to a special device or
a file that does not have the format that the application
expects.
Likelihood of Exploit
High to Very High
Detection Methods
Automated Static Analysis
The external control or influence of filenames can often be detected
using automated static analysis that models data flow within the
software.
Automated static analysis might not be able to recognize when proper
input validation is being performed, leading to false positives - i.e.,
warnings that do not have any security consequences or require any code
changes.
Demonstrative Examples
Example 1
The following code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files (CWE-22).
File rFile = new File("/usr/local/apfr/reports/" + rName);
...
rFile.delete();
Example 2
The following code uses input from a configuration file to determine
which file to open and echo back to the user. If the program runs with
privileges and malicious users can change the configuration file, they can
use the program to read any file on the system that ends with the extension
.txt.
(Bad Code)
Example
Language: Java
fis = new FileInputStream(cfg.getProperty("sub")+".txt");
Chain: external control of user's target language
enables remote file inclusion.
Potential Mitigations
Phase: Architecture and Design
When the set of filenames is limited or known, create a mapping from a
set of fixed input values (such as numeric IDs) to the actual filenames,
and reject all other inputs. For example, ID 1 could map to "inbox.txt"
and ID 2 could map to "profile.txt". Features such as the ESAPI
AccessReferenceMap provide this capability.
Phases: Architecture and Design; Operation
Run your code in a "jail" or similar sandbox environment that enforces
strict boundaries between the process and the operating system. This may
effectively restrict all access to files within a particular
directory.
Examples include the Unix chroot jail and AppArmor. In general,
managed code may provide some protection.
This may not be a feasible solution, and it only limits the impact to
the operating system; the rest of your application may still be subject
to compromise.
Be careful to avoid CWE-243 and other weaknesses related to jails.
Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
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.
When validating filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a whitelist of allowable file extensions, which will help to avoid CWE-434.
Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a blacklist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Phase: Implementation
Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59).
Phases: Installation; Operation
Use OS-level permissions and run as a low-privileged user to limit the
scope of any successful attack.
Phases: Operation; Implementation
If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
Phase: Testing
Use automated static analysis tools that target this type of weakness.
Many modern techniques use data flow analysis to minimize the number of
false positives. This is not a perfect solution, since 100% accuracy and
coverage are not feasible.
Phase: Testing
Use dynamic tools and techniques that interact with the software using
large test suites with many diverse inputs, such as fuzz testing
(fuzzing), robustness testing, and fault injection. The software's
operation may slow down, but it should not become unstable, crash, or
generate incorrect results.
Phase: Testing
Use tools and techniques that require manual (human) analysis, such as
penetration testing, threat modeling, and interactive tools that allow
the tester to record and modify an active session. These may be more
effective than strictly automated techniques. This is especially the
case with weaknesses that are related to design and business
rules.
Weakness Ordinalities
Ordinality
Description
Primary
(where
the weakness exists independent of other weaknesses)
The external control of filenames can be the primary link in chains with
other file-related weaknesses, as seen in the CanPrecede relationships. This
is because software systems use files for many different purposes: to
execute programs, load code libraries, to store application data, to store
configuration settings, record temporary data, act as signals or semaphores
to other processes, etc.
However, those weaknesses do not always require external control. For example, link-following weaknesses (CWE-59) often involve pathnames that are not controllable by the attacker at all.
The external control can be resultant from other issues. For example, in PHP applications, the register_globals setting can allow an attacker to modify variables that the programmer thought were immutable, enabling file inclusion (CWE-98) and path traversal (CWE-22). Operating with excessive privileges (CWE-250) might allow an attacker to specify an input filename that is not directly readable by the attacker, but is accessible to the privileged program. A buffer overflow (CWE-119) might give an attacker control over nearby memory locations that are related to pathnames, but were not directly modifiable by the attacker.
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
7 Pernicious Kingdoms
Path Manipulation
CERT C++ Secure Coding
FIO01-CPP
Be careful using functions that use file names for
identification
CERT C++ Secure Coding
FIO02-CPP
Canonicalize path names originating from untrusted
sources
The software does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
Extended Description
Access control involves the use of several protection mechanisms such as authentication (proving the identity of an actor) authorization (ensuring that a given actor can access a resource), and accountability (tracking of activities that were performed). When any mechanism is not applied or otherwise fails, attackers can compromise the security of the software by gaining privileges, reading sensitive information, executing commands, evading detection, etc.
There are two distinct behaviors that can introduce access control weaknesses:
Specification: incorrect privileges, permissions, ownership, etc. are explicitly specified for either the user or the resource (for example, setting a password file to be world-writable, or giving administrator capabilities to a guest user). This action could be performed by the program or the administrator.
Enforcement: the mechanism contains errors that prevent it from properly enforcing the specified access control requirements (e.g., allowing the user to specify their own privileges, or allowing a syntactically-incorrect ACL to produce insecure settings). This problem occurs within the program itself, in that it does not actually enforce the intended security policy that the administrator specifies.
Alternate Terms
Authorization:
The terms "access control" and "authorization" are often used
interchangeably, although many people have distinct definitions. The CWE
usage of "access control" is intended as a general term for the various
mechanisms that restrict which users can access which resources, and
"authorization" is more narrowly defined. It is unlikely that there will
be community consensus on the use of these terms.
Time of Introduction
Architecture and Design
Implementation
Operation
Common Consequences
Scope
Effect
Other
Technical Impact: Varies by context
Potential Mitigations
Phases: Architecture and Design; Operation
Very carefully manage the setting, management, and handling of
privileges. Explicitly manage trust zones in the software.
Phase: Architecture and Design
Strategy: Separation of Privilege
Compartmentalize the system to have "safe" areas where trust
boundaries can be unambiguously drawn. Do not allow sensitive data to go
outside of the trust boundary and always be careful when interfacing
with a compartment outside of the safe area.
Ensure that appropriate compartmentalization is built into the system
design and that the compartmentalization serves to allow for and further
reinforce privilege separation functionality. Architects and designers
should rely on the principle of least privilege to decide when it is
appropriate to use and to drop system privileges.
[REF-11] M. Howard and
D. LeBlanc. "Writing Secure Code". Chapter 6, "Determining Appropriate Access Control" Page
171. 2nd Edition. Microsoft. 2002.
[REF-17] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 17: Failure to Protect Stored Data." Page
253. McGraw-Hill. 2010.
Maintenance Notes
This item needs more work. Possible sub-categories include:
* Trusted group includes undesired entities (partially covered by CWE-286)
When an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct.
Alternate Terms
authentification:
An alternate term is "authentification", which appears to be most
commonly used by people from non-English-speaking countries.
AuthC:
"AuthC" is typically used as an abbreviation of "authentication"
within the web application security community. It is also distinct from
"AuthZ," which is an abbreviation of "authorization." The use of "Auth"
as an abbreviation is discouraged, since it could be used for either
authentication or authorization.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
Language-independent
Common Consequences
Scope
Effect
Integrity
Confidentiality
Availability
Access Control
Technical Impact: Read application
data; Gain privileges / assume
identity; Execute unauthorized code or
commands
This weakness can lead to the exposure of resources or functionality
to unintended actors, possibly providing attackers with sensitive
information or even execute arbitrary code.
Likelihood of Exploit
Medium to High
Detection Methods
Automated Static Analysis
Automated static analysis is useful for detecting certain types of
authentication. A tool may be able to analyze related configuration
files, such as .htaccess in Apache web servers, or detect the usage of
commonly-used authentication libraries.
Generally, automated static analysis tools have difficulty detecting
custom authentication schemes. In addition, the software's design may
include some functionality that is accessible to any user and does not
require an established identity; an automated technique that detects the
absence of authentication may report false positives.
Effectiveness: Limited
Manual Static Analysis
This weakness can be detected using tools and techniques that require
manual (human) analysis, such as penetration testing, threat modeling,
and interactive tools that allow the tester to record and modify an
active session.
Manual static analysis is useful for evaluating the correctness of
custom authentication mechanisms.
Effectiveness: High
These may be more effective than strictly automated techniques. This
is especially the case with weaknesses that are related to design and
business rules.
Demonstrative Examples
Example 1
The following code intends to ensure that the user is already logged
in. If not, the code performs authentication with the user-provided username
and password. If successful, it sets the loggedin and user cookies to
"remember" that the user has already logged in. Finally, the code performs
administrator tasks if the logged-in user has the "Administrator" username,
as recorded in the user cookie.
(Bad Code)
Example
Language: Perl
my $q = new CGI;
if ($q->cookie('loggedin') ne "true") {
if (! AuthenticateUser($q->param('username'),
$q->param('password'))) {
ExitError("Error: you need to log in first");
}
else {
# Set loggedin and user cookies.
$q->cookie(
-name => 'loggedin',
-value => 'true'
);
$q->cookie(
-name => 'user',
-value => $q->param('username')
);
}
}
if ($q->cookie('user') eq "Administrator") {
DoAdministratorTasks();
}
Unfortunately, this code can be bypassed. The attacker can set the
cookies independently so that the code does not check the username and
password. The attacker could do this with an HTTP request containing
headers such as:
(Attack)
GET /cgi-bin/vulnerable.cgi HTTP/1.1
Cookie: user=Administrator
Cookie: loggedin=true
[body of request]
By setting the loggedin cookie to "true", the attacker bypasses the
entire authentication check. By using the "Administrator" value in the
user cookie, the attacker also gains privileges to administer the
software.
Example 2
In January 2009, an attacker was able to gain administrator access
to a Twitter server because the server did not restrict the number of login
attempts. The attacker targeted a member of Twitter's support team and was
able to successfully guess the member's password using a brute force with a
large number of common words. Once the attacker gained access as the member
of the support staff, he used the administrator panel to gain access to 33
accounts that belonged to celebrities and politicians. Ultimately, fake
Twitter messages were sent that appeared to come from the compromised
accounts.
The software does not perform or incorrectly performs an authorizationcheck when an actor attempts to access a resource or perform an action.
Extended Description
Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.
When access control checks are not applied consistently - or not at all - users are able to access data or perform actions that they should not be allowed to perform. This can lead to a wide range of problems, including information exposures, denial of service, and arbitrary code execution.
Alternate Terms
AuthZ:
"AuthZ" is typically used as an abbreviation of "authorization" within
the web application security community. It is also distinct from
"AuthC," which is an abbreviation of "authentication." The use of "Auth"
as an abbreviation is discouraged, since it could be used for either
authentication or authorization.
Time of Introduction
Architecture and Design
Implementation
Operation
Applicable Platforms
Languages
Language-independent
Technology Classes
Web-Server: (Often)
Database-Server: (Often)
Modes of Introduction
A developer may introduce authorization weaknesses because of a lack of
understanding about the underlying technologies. For example, a developer
may assume that attackers cannot modify certain inputs such as headers or
cookies.
Authorization weaknesses may arise when a single-user application is
ported to a multi-user environment.
Common Consequences
Scope
Effect
Confidentiality
Technical Impact: Read application
data; Read files or
directories
An attacker could read sensitive data, either by reading the data
directly from a data store that is not properly restricted, or by
accessing insufficiently-protected, privileged functionality to read the
data.
Integrity
Technical Impact: Modify application
data; Modify files or
directories
An attacker could modify sensitive data, either by writing the data
directly to a data store that is not properly restricted, or by
accessing insufficiently-protected, privileged functionality to write
the data.
Access Control
Technical Impact: Gain privileges / assume
identity
An attacker could gain privileges by modifying or reading critical
data directly, or by accessing insufficiently-protected, privileged
functionality.
Likelihood of Exploit
High
Detection Methods
Automated Static Analysis
Automated static analysis is useful for detecting commonly-used idioms
for authorization. A tool may be able to analyze related configuration
files, such as .htaccess in Apache web servers, or detect the usage of
commonly-used authorization libraries.
Generally, automated static analysis tools have difficulty detecting
custom authorization schemes. In addition, the software's design may
include some functionality that is accessible to any user and does not
require an authorization check; an automated technique that detects the
absence of authorization may report false positives.
Effectiveness: Limited
Automated Dynamic Analysis
Automated dynamic analysis may find many or all possible interfaces
that do not require authorization, but manual analysis is required to
determine if the lack of authorization violates business logic
Manual Analysis
This weakness can be detected using tools and techniques that require
manual (human) analysis, such as penetration testing, threat modeling,
and interactive tools that allow the tester to record and modify an
active session.
Specifically, manual static analysis is useful for evaluating the
correctness of custom authorization mechanisms.
Effectiveness: Moderate
These may be more effective than strictly automated techniques. This
is especially the case with weaknesses that are related to design and
business rules. However, manual efforts might not achieve desired code
coverage within limited time constraints.
Demonstrative Examples
Example 1
This function runs an arbitrary SQL query on a given database,
returning the result of the query.
(Bad Code)
Example
Language: PHP
function runEmployeeQuery($dbName, $name){
mysql_select_db($dbName,$globalDbHandle) or die("Could not
open Database".$dbName);
//Use a prepared statement to avoid CWE-89
$preparedStatement = $globalDbHandle->prepare('SELECT
* FROM employees WHERE name = :name');
While this code is careful to avoid SQL Injection, the function does
not confirm the user sending the query is authorized to do so. An
attacker may be able to obtain sensitive employee information from the
database.
Example 2
The following program could be part of a bulletin board system that
allows users to send private messages to each other. This program intends to
authenticate the user before deciding whether a private message should be
displayed. Assume that LookupMessageObject() ensures that the $id argument
is numeric, constructs a filename based on that id, and reads the message
details from that file. Also assume that the program stores all private
messages for all users in the same directory.
# For purposes of this example, assume that CWE-309
and
# CWE-523 do not apply.
if (! AuthenticateUser($q->param('username'),
$q->param('password'))) {
ExitError("invalid username or password");
}
my $id = $q->param('id');
DisplayPrivateMessage($id);
While the program properly exits if authentication fails, it does not
ensure that the message is addressed to the user. As a result, an
authenticated attacker could provide any arbitrary identifier and read
private messages that were intended for other users.
One way to avoid this problem would be to ensure that the "to" field
in the message object matches the username of the authenticated user.
Chain: SNMP product does not properly parse a
configuration option for which hosts are allowed to connect, allowing
unauthorized IP addresses to connect.
Chain: product does not properly check the result of a reverse DNS lookup because of operator precedence (CWE-783), allowing bypass of DNS-based access restrictions.
Potential Mitigations
Phase: Architecture and Design
Divide the software into anonymous, normal, privileged, and
administrative areas. Reduce the attack surface by carefully mapping
roles with data and functionality. Use role-based access control (RBAC)
to enforce the roles at the appropriate boundaries.
Note that this approach may not protect against horizontal
authorization, i.e., it will not protect a user from attacking others
with the same role.
Phase: Architecture and Design
Ensure that you perform access control checks related to your business
logic. These checks may be different than the access control checks that
you apply to more generic resources such as files, connections,
processes, memory, and database records. For example, a database may
restrict access for medical records to a specific database user, but
each record might only be intended to be accessible to the patient and
the patient's doctor.
Phase: Architecture and Design
Strategy: Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to
occur or provides constructs that make this weakness easier to
avoid.
For example, consider using authorization frameworks such as the JAAS Authorization Framework [R.285.5] and the OWASP ESAPI Access Control feature [R.285.4].
Phase: Architecture and Design
For web applications, make sure that the access control mechanism is
enforced correctly at the server side on every page. Users should not be
able to access any unauthorized functionality or information by simply
requesting direct access to that page.
One way to do this is to ensure that all pages containing sensitive
information are not cached, and that all such pages restrict access to
requests that are accompanied by an active and authenticated session
token associated with a user who has the required permissions to access
that page.
Phases: System Configuration; Installation
Use the access control capabilities of your operating system and
server environment and define your access control lists accordingly. Use
a "default deny" policy when defining these ACLs.
Background Details
An access control list (ACL) represents who/what has permissions to a
given object. Different operating systems implement (ACLs) in different
ways. In UNIX, there are three types of permissions: read, write, and
execute. Users are divided into three classes for file access: owner, group
owner, and all other users where each class has a separate set of rights. In
Windows NT, there are four basic types of permissions for files: "No
access", "Read access", "Change access", and "Full control". Windows NT
extends the concept of three types of users in UNIX to include a list of
users and groups along with their associated permissions. A user can create
an object (file) and assign specified permissions to that object.
[R.285.6] [REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Authorization", Page
39.. 1st Edition. Addison Wesley. 2006.
[R.285.7] [REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 11, "ACL Inheritance", Page 649.. 1st Edition. Addison Wesley. 2006.
The software does not validate, or incorrectly validates, a certificate.
Extended Description
When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
Language-independent
Architectural Paradigms
Mobile Application
Common Consequences
Scope
Effect
Integrity
Authentication
Technical Impact: Bypass protection
mechanism; Gain privileges / assume
identity
Web browser uses a TLS-related function
incorrectly, preventing it from verifying that a server's certificate is
signed by a trusted certification authority
(CA)
chain: DNS server does not correctly check return
value from the OpenSSL EVP_VerifyFinal function allows bypass of validation
of the certificate chain.
chain: OS package manager does not check properly
check the return value, allowing bypass using a revoked
certificate.
Potential Mitigations
Phases: Architecture and Design; Implementation
Certificates should be carefully managed and checked to assure that
data are encrypted with the intended owner's public key.
Background Details
A certificate is a token that associates an identity (principle) to a
cryptographic key. Certificates can be used to check if a public key belongs
to the assumed owner.
Creating a Rogue Certificate Authority Certificate
References
Sascha Fahl, Marian Harbach, Thomas Muders, Matthew
Smith and
Lars Baumgärtner, Bernd Freisleben. "Why Eve and Mallory Love Android: An Analysis of Android SSL
(In)Security". 2012-10-16. <http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf>.
M. Bishop. "Computer Security: Art and Science". Addison-Wesley. 2003.
Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
Definition in a New Window
Weakness ID: 98 (Weakness Base)
Status: Draft
Description
Description Summary
The PHP application receives input from an upstream component, but it does not restrict or incorrectly restricts the input before its usage in "require," "include," or similar functions.
Extended Description
In certain versions and configurations of PHP, this can allow an attacker to specify a URL to a remote location from which the software will obtain the code to execute. In other cases in association with path traversal, the attacker can specify a local file that may contain executable statements that can be parsed by PHP.
Alternate Terms
Remote file include
RFI:
The Remote File Inclusion (RFI) acronym is often used by vulnerability
researchers.
Local file inclusion:
This term is frequently used in cases in which remote download is disabled, or when the first part of the filename is not under the attacker's control, which forces use of relative path traversal (CWE-23) attack techniques to access files that may contain previously-injected PHP code, such as web access logs.
Time of Introduction
Implementation
Architecture and Design
Applicable Platforms
Languages
PHP: (Often)
Common Consequences
Scope
Effect
Integrity
Confidentiality
Availability
Technical Impact: Execute unauthorized code or
commands
The attacker may be able to specify arbitrary code to be executed from
a remote location. Alternatively, it may be possible to use normal
program behavior to insert php code into files on the local machine
which can then be included and force the code to execute since php
ignores everything in the file except for the content between php
specifiers.
Likelihood of Exploit
High to Very High
Detection Methods
Manual Analysis
Manual white-box analysis can be very effective for finding this
issue, since there is typically a relatively small number of include or
require statements in each program.
Effectiveness: High
Automated Static Analysis
The external control or influence of filenames can often be detected
using automated static analysis that models data flow within the
software.
Automated static analysis might not be able to recognize when proper
input validation is being performed, leading to false positives - i.e.,
warnings that do not have any security consequences or require any code
changes. If the program uses a customized input validation library, then
some tools may allow the analyst to create custom signatures to detect
usage of those routines.
Demonstrative Examples
Example 1
The following code attempts to include a function contained in a
separate PHP page on the server. It builds the path to the file by using the
supplied 'module_name' parameter and appending the string '/function.php' to
it.
victim.php
(Bad Code)
Example
Language: PHP
$dir = $_GET['module_name'];
include($dir . "/function.php");
The problem with the above code is that the value of $dir is not
restricted in any way, and a malicious user could manipulate the
'module_name' parameter to force inclusion of an unanticipated file. For
example, an attacker could request the above PHP page (example.php) with
a 'module_name' of "http://malicious.example.com" by using the following
request string:
Upon receiving this request, the code would set 'module_name' to the
value "http://malicious.example.com" and would attempt to include
http://malicious.example.com/function.php, along with any malicious code
it contains.
For the sake of this example, assume that the malicious version of
function.php looks like the following:
(Bad Code)
system($_GET['cmd']);
An attacker could now go a step further in our example and provide a
request string as follows:
The code will attempt to include the malicious function.php file from
the remote site. In turn, this file executes the command specified in
the 'cmd' parameter from the query string. The end result is an attempt
by tvictim.php to execute the potentially malicious command, in this
case:
(Attack)
/bin/ls -l
Note that the above PHP example can be mitigated by setting
allow_url_fopen to false, although this will not fully protect the code.
See potential mitigations.
PHP file inclusion issue, both remote and local;
local include uses ".." and "%00" characters as a manipulation, but many
remote file inclusion issues probably have this
vector.
chain: library file sends a redirect if it is
directly requested but continues to execute, allowing remote file inclusion
and path traversal.
Potential Mitigations
Phase: Architecture and Design
Strategy: Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to
occur or provides constructs that make this weakness easier to
avoid.
Phase: Architecture and Design
Strategy: Enforcement by Conversion
When the set of acceptable objects, such as filenames or URLs, is
limited or known, create a mapping from a set of fixed input values
(such as numeric IDs) to the actual filenames or URLs, and reject all
other inputs.
For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [R.98.1] provide this capability.
Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Phases: Architecture and Design; Operation
Strategy: Sandbox or Jail
Run the code in a "jail" or similar sandbox environment that enforces
strict boundaries between the process and the operating system. This may
effectively restrict which files can be accessed in a particular
directory or which commands can be executed by the software.
OS-level examples include the Unix chroot jail, AppArmor, and SELinux.
In general, managed code may provide some protection. For example,
java.io.FilePermission in the Java SecurityManager allows the software
to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to
the operating system; the rest of the application may still be subject
to compromise.
Be careful to avoid CWE-243 and other weaknesses related to jails.
Effectiveness: Limited
The effectiveness of this mitigation depends on the prevention
capabilities of the specific sandbox or jail being used and might only
help to reduce the scope of an attack, such as restricting the attacker
to certain system calls or limiting the portion of the file system that
can be accessed.
Phases: Architecture and Design; Operation
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.98.2]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
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.
When validating filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a whitelist of allowable file extensions, which will help to avoid CWE-434.
Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a blacklist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Phases: Architecture and Design; Operation
Strategy: Identify and Reduce Attack Surface
Store library, include, and utility files outside of the web document
root, if possible. Otherwise, store them in a separate directory and use
the web server's access control capabilities to prevent attackers from
directly requesting them. One common practice is to define a fixed
constant in each calling program, then check for the existence of the
constant in the library/include file; if the constant does not exist,
then the file was directly requested, and it can exit
immediately.
This significantly reduces the chance of an attacker being able to
bypass any protection mechanisms that are in the base program but not in
the include files. It will also reduce the attack surface.
Phases: Architecture and Design; Implementation
Strategy: Identify and Reduce Attack Surface
Understand all the potential areas where untrusted inputs can enter
your software: parameters or arguments, cookies, anything read from the
network, environment variables, reverse DNS lookups, query results,
request headers, URL components, e-mail, files, filenames, databases,
and any external systems that provide data to the application. Remember
that such inputs may be obtained indirectly through API calls.
Many file inclusion problems occur because the programmer assumed that
certain inputs could not be modified, especially for cookies and URL
components.
Phase: Operation
Strategy: Firewall
Use an application firewall that can detect attacks against this
weakness. It can be beneficial in cases in which the code cannot be
fixed (because it is controlled by a third party), as an emergency
prevention measure while more comprehensive software assurance measures
are applied, or to provide defense in depth.
Effectiveness: Moderate
An application firewall might not cover all possible input vectors. In
addition, attack techniques might be available to bypass the protection
mechanism, such as using malformed inputs that can still be processed by
the component that receives those inputs. Depending on functionality, an
application firewall might inadvertently reject or modify legitimate
requests. Finally, some manual effort may be required for
customization.
Phases: Operation; Implementation
Strategy: Environment Hardening
Develop and run your code in the most recent versions of PHP
available, preferably PHP 6 or later. Many of the highly risky features
in earlier PHP interpreters have been removed, restricted, or disabled
by default.
Phases: Operation; Implementation
Strategy: Environment Hardening
When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
Often, programmers do not protect direct access to files intended only
to be included by core programs. These include files may assume that
critical variables have already been initialized by the calling program.
As a result, the use of register_globals combined with the ability to
directly access the include file may allow attackers to conduct file
inclusion attacks. This remains an extremely common pattern as of
2009.
Phase: Operation
Strategy: Environment Hardening
Set allow_url_fopen to false, which limits the ability to include
files from remote locations.
Effectiveness: High
Be aware that some versions of PHP will still accept ftp:// and other URI schemes. In addition, this setting does not protect the code from path traversal attacks (CWE-22), which are frequently successful against the same vulnerable code that allows remote file inclusion.
This is frequently a functional consequence of other weaknesses. It is
usually multi-factor with other factors (e.g. MAID), although not all
inclusion bugs involve assumed-immutable data. Direct request weaknesses
frequently play a role.
Can overlap directory traversal in local inclusion problems.
Research Gaps
Under-researched and under-reported. Other interpreted languages with
"require" and "include" functionality could also product vulnerable
applications, but as of 2007, PHP has been the focus. Any web-accessible
language that uses executable file extensions is likely to have this type of
issue, such as ASP, since .asp extensions are typically executable.
Languages such as Perl are less likely to exhibit these problems because the
.pl extension isn't always configured to be executable by the web
server.
Improper Following of a Certificate's Chain of Trust
Definition in a New Window
Weakness ID: 296 (Weakness Base)
Status: Draft
Description
Description Summary
The software does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate.
Extended Description
If a system does not follow the chain of trust of a certificate to a root server, the certificate loses all usefulness as a metric of trust. Essentially, the trust gained from a certificate is derived from a chain of trust -- with a reputable trusted entity at the end of that list. The end user must trust that reputable source, and this reputable source must vouch for the resource in question through the medium of the certificate.
In some cases, this trust traverses several entities who vouch for one another. The entity trusted by the end user is at one end of this trust chain, while the certificate-wielding resource is at the other end of the chain. If the user receives a certificate at the end of one of these trust chains and then proceeds to check only that the first link in the chain, no real trust has been derived, since the entire chain must be traversed back to a trusted source to verify the certificate.
There are several ways in which the chain of trust might be broken, including but not limited to:
Any certificate in the chain is self-signed, unless it the root.
Not every intermediate certificate is checked, starting from the original certificate all the way up to the root certificate.
An intermediate, CA-signed certificate does not have the expected Basic Constraints or other important extensions.
The root certificate has been compromised or authorized to the wrong party.
Time of Introduction
Architecture and Design
Applicable Platforms
Languages
Language-independent
Common Consequences
Scope
Effect
Non-Repudiation
Technical Impact: Hide activities
Exploitation of this flaw can lead to the trust of data that may have
originated with a spoofed source.
Integrity
Confidentiality
Availability
Access Control
Technical Impact: Gain privileges / assume
identity; Execute unauthorized code or
commands
Data, requests, or actions taken by the attacking entity can be
carried out as a spoofed benign entity.
Likelihood of Exploit
Low
Demonstrative Examples
Example 1
(Bad Code)
Example Languages: C and C++
if ((cert = SSL_get_peer_certificate(ssl)) &&
host)
foo=SSL_get_verify_result(ssl);
if ((X509_V_OK==foo) ||
X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN==foo))
// certificate looks good, host can be trusted
In this case, because the certificate is self-signed, there was no
external authority that could prove the identity of the host. The
program could be communicating with a different system that is spoofing
the host, e.g. by poisoning the DNS cache or conducting a
man-in-the-middle attack.
Chain: Web browser uses a TLS-related function
incorrectly, preventing it from verifying that a server's certificate is
signed by a trusted certification authority
(CA).
chain: DNS server does not correctly check return
value from the OpenSSL EVP_VerifyFinal function allows bypass of validation
of the certificate chain.
Failure to follow chain of trust in certificate
validation
References
Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh
and Vitaly Shmatikov. "The Most Dangerous Code in the World: Validating SSL
Certificates in Non-Browser Software". 2012-10-25. <http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>.
[REF-17] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 23: Improper Use of PKI, Especially SSL." Page
347. McGraw-Hill. 2010.
The software receives input from an upstream component, but it does not handle or incorrectly handles when an additional unexpectedspecial element is missing.
Developers should anticipate that extra special elements will be
injected in the input vectors of their software system. Use an
appropriate combination of black lists and white lists to ensure only
valid, expected and appropriate input is processed by the system.
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: Output Encoding
While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict whitelist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).
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.
HTTP GET without \r\n\r\n CRLF sequences causes
product to wait indefinitely and prevents other users from accessing
it
Potential Mitigations
Developers should anticipate that special elements will be removed in
the input vectors of their software system. Use an appropriate
combination of black lists and white lists to ensure only valid,
expected and appropriate input is processed by the system.
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.
If an input is syntactically invalid, then processing the input could
place the system in an unexpected state that could lead to a crash,
consume available system resources or other unintended behaviors.
This entry needs more investigation. Public vulnerability research generally focuses on the manipulations that generate invalid structure, instead of the weaknesses that are exploited by those manipulations. For example, a common attack involves making a request that omits a required field, which can trigger a crash in some cases. The crash could be due to a named chain such as CWE-690 (Unchecked Return Value to NULL Pointer Dereference), but public reports rarely cover this aspect of a vulnerability.
The validity of input could be roughly classified along "syntactic",
"semantic", and "lexical" dimensions. If the specification requires that an
input value should be delimited with the "[" and "]" square brackets, then
any input that does not follow this specification would be syntactically
invalid. If the input between the brackets is expected to be a number, but
the letters "aaa" are provided, then the input is syntactically invalid. If
the input is a number and enclosed in brackets, but the number is outside of
the allowable range, then it is semantically invalid. The
inter-relationships between these properties - and their associated
weaknesses- need further exploration.
The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.
Extended Description
When software does not validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application. This will lead to parts of the system receiving unintended input, which may result in altered control flow, arbitrary control of a resource, or arbitrary code execution.
Terminology Notes
The "input validation" term is extremely common, but it is used in many
different ways. In some cases its usage can obscure the real underlying
weakness or otherwise hide chaining and composite relationships.
Some people use "input validation" as a general term that covers many
different neutralization techniques for ensuring that input is appropriate,
such as filtering, canonicalization, and escaping. Others use the term in a
more narrow context to simply mean "checking if an input conforms to
expectations without changing it."
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
Language-independent
Platform Notes
Input validation can be a problem in any system that receives data from an
external source.
Modes of Introduction
If a programmer believes that an attacker cannot modify certain inputs, then the programmer might not perform any input validation at all. For example, in web applications, many programmers believe that cookies and hidden form fields can not be modified from a web browser (CWE-472), although they can be altered using a proxy or a custom program. In a client-server architecture, the programmer might assume that client-side security checks cannot be bypassed, even when a custom client could be written that skips those checks (CWE-602).
An attacker could provide unexpected values and cause a program crash
or excessive consumption of resources, such as memory and CPU.
Confidentiality
Technical Impact: Read memory; Read files or
directories
An attacker could read confidential data if they are able to control
resource references.
Integrity
Confidentiality
Availability
Technical Impact: Modify memory; Execute unauthorized code or
commands
An attacker could use malicious input to modify data or possibly alter
control flow in unexpected ways, including arbitrary command
execution.
Likelihood of Exploit
High
Detection Methods
Automated Static Analysis
Some instances of improper input validation can be detected using
automated static analysis.
A static analysis tool might allow the user to specify which
application-specific methods or functions perform input validation; the
tool might also have built-in knowledge of validation frameworks such as
Struts. The tool may then suppress or de-prioritize any associated
warnings. This allows the analyst to focus on areas of the software in
which input validation does not appear to be present.
Except in the cases described in the previous paragraph, automated
static analysis might not be able to recognize when proper input
validation is being performed, leading to false positives - i.e.,
warnings that do not have any security consequences or require any code
changes.
Manual Static Analysis
When custom input validation is required, such as when enforcing
business rules, manual analysis is necessary to ensure that the
validation is properly implemented.
Fuzzing
Fuzzing techniques can be useful for detecting input validation
errors. When unexpected inputs are provided to the software, the
software should not crash or otherwise become unstable, and it should
generate application-controlled error messages. If exceptions or
interpreter-generated error messages occur, this indicates that the
input was not detected and handled within the application logic
itself.
Demonstrative Examples
Example 1
This example demonstrates a shopping interaction in which the user
is free to specify the quantity of items to be purchased and a total is
calculated.
(Bad Code)
Example
Language: Java
...
public static final double price = 20.00;
int quantity = currentUser.getAttribute("quantity");
double total = price * quantity;
chargeUser(total);
...
The user has no control over the price variable, however the code does
not prevent a negative value from being specified for quantity. If an
attacker were to provide a negative value, then the user would have
their account credited instead of debited.
Example 2
This example asks the user for a height and width of an m X n game
board with a maximum dimension of 100 squares.
(Bad Code)
Example
Language: C
...
#define MAX_DIM 100
...
/* board dimensions */
int m,n, error;
board_square_t *board;
printf("Please specify the board height: \n");
error = scanf("%d", &m);
if ( EOF == error ){
die("No integer passed: Die evil hacker!\n");
}
printf("Please specify the board width: \n");
error = scanf("%d", &n);
if ( EOF == error ){
die("No integer passed: Die evil hacker!\n");
}
if ( m > MAX_DIM || n > MAX_DIM ) {
die("Value too large: Die evil hacker!\n");
}
board = (board_square_t*) malloc( m * n *
sizeof(board_square_t));
...
While this code checks to make sure the user cannot specify large, positive integers and consume too much memory, it does not check for negative values supplied by the user. As a result, an attacker can perform a resource consumption (CWE-400) attack against this program by specifying two, large negative values that will not overflow, resulting in a very large memory allocation (CWE-789) and possibly a system crash. Alternatively, an attacker can provide very large negative values which will cause an integer overflow (CWE-190) and unexpected behavior will follow depending on how the values are treated in the remainder of the program.
Example 3
The following example shows a PHP application in which the
programmer attempts to display a user's birthday and homepage.
The programmer intended for $birthday to be in a date format and
$homepage to be a valid URL. However, since the values are derived from
an HTTP request, if an attacker can trick a victim into clicking a
crafted URL with <script> tags providing the values for
birthday and / or homepage, then the script will run on the client's
browser when the web server echoes the content. Notice that even if the
programmer were to defend the $birthday variable by restricting input to
integers and dashes, it would still be possible for an attacker to
provide a string of the form:
(Attack)
2009-01-09--
If this data were used in a SQL statement, it would treat the
remainder of the statement as a comment. The comment could disable other
security-related logic in the statement. In this case, encoding combined
with input validation would be a more useful protection
mechanism.
Furthermore, an XSS (CWE-79) attack or SQL injection (CWE-89) are just a few of the potential consequences when input validation is not used. Depending on the context of the code, CRLF Injection (CWE-93), Argument Injection (CWE-88), or Command Injection (CWE-77) may also be possible.
Example 4
This function attempts to extract a pair of numbers from a
user-supplied string.
(Bad Code)
Example
Language: C
void parse_data(char *untrusted_input){
int m, n, error;
error = sscanf(untrusted_input, "%d:%d", &m,
&n);
if ( EOF == error ){
die("Did not specify integer value. Die evil
hacker!\n");
}
/* proceed assuming n and m are initialized correctly
*/
}
This code attempts to extract two integer values out of a formatted,
user-supplied input. However, if an attacker were to provide an input of
the form:
(Attack)
123:
then only the m variable will be initialized. Subsequent use of n may result in the use of an uninitialized variable (CWE-457).
Example 5
The following example takes a user-supplied value to allocate an
array of objects and then operates on the array.
(Bad Code)
Example
Language: Java
private void buildList ( int untrustedListSize ){
if ( 0 > untrustedListSize ){
die("Negative value supplied for list size, die evil
hacker!");
}
Widget[] list = new Widget [ untrustedListSize ];
list[0] = new Widget();
}
This example attempts to build a list from a user-specified value, and
even checks to ensure a non-negative value is supplied. If, however, a 0
value is provided, the code will build an array of size 0 and then try
to store a new Widget in the first location, causing an exception to be
thrown.
crash via multiple "." characters in file
extension
Potential Mitigations
Phase: Architecture and Design
Strategies: Input Validation; Libraries or Frameworks
Use an input validation framework such as Struts or the OWASP ESAPI Validation API. If you use Struts, be mindful of weaknesses covered by the CWE-101 category.
Phases: Architecture and Design; Implementation
Strategy: Identify and Reduce Attack Surface
Understand all the potential areas where untrusted inputs can enter
your software: parameters or arguments, cookies, anything read from the
network, environment variables, reverse DNS lookups, query results,
request headers, URL components, e-mail, files, filenames, databases,
and any external systems that provide data to the application. Remember
that such inputs may be obtained indirectly through API calls.
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: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Even though client-side checks provide minimal benefits with respect
to server-side security, they are still useful. First, they can support
intrusion detection. If the server receives input that should have been
rejected by the client, then it may be an indication of an attack.
Second, client-side error-checking can provide helpful feedback to the
user about the expectations for valid input. Third, there may be a
reduction in server-side processing time for accidental input errors,
although this is typically a small savings.
Phase: Implementation
When your application combines data from multiple sources, perform the
validation after the sources have been combined. The individual data
elements may pass the validation step but violate the intended
restrictions after they have been combined.
Phase: Implementation
Be especially careful to validate all input when invoking code that
crosses language boundaries, such as from an interpreted language to
native code. This could create an unexpected interaction between the
language boundaries. Ensure that you are not violating any of the
expectations of the language with which you are interfacing. For
example, even though Java may not be susceptible to buffer overflows,
providing a large argument in a call to native code might trigger an
overflow.
Phase: Implementation
Directly convert your input type into the expected data type, such as
using a conversion function that translates a string into a number.
After converting to the expected data type, ensure that the input's
values fall within the expected range of allowable values and that
multi-field consistencies are maintained.
Phase: Implementation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.
Consider performing repeated canonicalization until your input does
not change any more. This will avoid double-decoding and similar
scenarios, but it might inadvertently modify inputs that are allowed to
contain properly-encoded dangerous content.
Phase: Implementation
When exchanging data between components, ensure that both components
are using the same character encoding. Ensure that the proper encoding
is applied at each interface. Explicitly set the encoding you are using
whenever the protocol allows you to do so.
Phase: Testing
Use automated static analysis tools that target this type of weakness.
Many modern techniques use data flow analysis to minimize the number of
false positives. This is not a perfect solution, since 100% accuracy and
coverage are not feasible.
Phase: Testing
Use dynamic tools and techniques that interact with the software using
large test suites with many diverse inputs, such as fuzz testing
(fuzzing), robustness testing, and fault injection. The software's
operation may slow down, but it should not become unstable, crash, or
generate incorrect results.
CWE-116 and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message. For example, by validating that a numeric ID field should only contain the 0-9 characters, the programmer effectively prevents injection attacks.
However, input validation is not always sufficient, especially when less
stringent data types must be supported, such as free-form text. Consider a
SQL injection scenario in which a last name is inserted into a query. The
name "O'Reilly" would likely pass the validation step since it is a common
last name in the English language. However, it cannot be directly inserted
into the database because it contains the "'" apostrophe character, which
would need to be escaped or otherwise neutralized. In this case, stripping
the apostrophe might reduce the risk of SQL injection, but it would produce
incorrect behavior because the wrong name would be recorded.
Research Gaps
There is not much research into the classification of input validation
techniques and their application. Many publicly-disclosed vulnerabilities
simply characterize a problem as "input validation" without providing more
specific details that might contribute to a deeper understanding of
validation techniques and the weaknesses they can prevent or reduce.
Validation is over-emphasized in contrast to other neutralization techniques
such as filtering and enforcement by conversion. See the vulnerability
theory paper.
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
7 Pernicious Kingdoms
Input validation and representation
OWASP Top Ten 2004
A1
CWE_More_Specific
Unvalidated Input
CERT C Secure Coding
ERR07-C
Prefer functions that support error checking over equivalent
functions that don't
CERT C Secure Coding
INT06-C
Use strtol() or a related function to convert a string token
to an integer
CERT C Secure Coding
MEM10-C
Define and use a pointer validation
function
CERT C Secure Coding
MSC08-C
Library functions should validate their
parameters
WASC
20
Improper Input Handling
CERT C++ Secure Coding
INT06-CPP
Use strtol() or a related function to convert a string token
to an integer
[REF-11] M. Howard and
D. LeBlanc. "Writing Secure Code". Chapter 10, "All Input Is Evil!" Page 341. 2nd Edition. Microsoft. 2002.
Maintenance Notes
Input validation - whether missing or incorrect - is such an essential and widespread part of secure development that it is implicit in many different weaknesses. Traditionally, problems such as buffer overflows and XSS have been classified as input validation problems by many security professionals. However, input validation is not necessarily the only protection mechanism available for avoiding such problems, and in some cases it is not even sufficient. The CWE team has begun capturing these subtleties in chains within the Research Concepts view (CWE-1000), but more work is needed.
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Definition in a New Window
Weakness ID: 22 (Weakness Class)
Status: Draft
Description
Description Summary
The software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the software does not properly neutralizespecial elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
Extended Description
Many file operations are intended to take place within a restricted directory. By using special elements such as ".." and "/" separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the "../" sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as "/usr/local/bin", which may also be useful in accessing unexpected files. This is referred to as absolute path traversal.
In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to widen the scope of attack. For example, the software may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.
Alternate Terms
Directory traversal
Path traversal:
"Path traversal" is preferred over "directory traversal," but both
terms are attack-focused.
Terminology Notes
Like other weaknesses, terminology is often based on the types of
manipulations used, instead of the underlying weaknesses. Some people use
"directory traversal" only to refer to the injection of ".." and equivalent
sequences whose specific meaning is to traverse directories.
Other variants like "absolute pathname" and "drive letter" have the
*effect* of directory traversal, but some people may not call it such, since
it doesn't involve ".." or equivalent.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
Language-independent
Common Consequences
Scope
Effect
Integrity
Confidentiality
Availability
Technical Impact: Execute unauthorized code or
commands
The attacker may be able to create or overwrite critical files that
are used to execute code, such as programs or libraries.
Integrity
Technical Impact: Modify files or
directories
The attacker may be able to overwrite or create critical files, such
as programs, libraries, or important data. If the targeted file is used
for a security mechanism, then the attacker may be able to bypass that
mechanism. For example, appending a new account at the end of a password
file may allow an attacker to bypass authentication.
Confidentiality
Technical Impact: Read files or
directories
The attacker may be able read the contents of unexpected files and
expose sensitive data. If the targeted file is used for a security
mechanism, then the attacker may be able to bypass that mechanism. For
example, by reading a password file, the attacker could conduct brute
force password guessing attacks in order to break into an account on the
system.
Availability
Technical Impact: DoS: crash / exit /
restart
The attacker may be able to overwrite, delete, or corrupt unexpected
critical files such as programs, libraries, or important data. This may
prevent the software from working at all and in the case of a protection
mechanisms such as authentication, it has the potential to lockout every
user of the software.
Likelihood of Exploit
High to Very High
Detection Methods
Automated Static Analysis
Automated techniques can find areas where path traversal weaknesses
exist. However, tuning or customization may be required to remove or
de-prioritize path-traversal problems that are only exploitable by the
software's administrator - or other privileged users - and thus
potentially valid behavior or, at worst, a bug instead of a
vulnerability.
Effectiveness: High
Manual Static Analysis
Manual white box techniques may be able to provide sufficient code
coverage and reduction of false positives if all file access operations
can be assessed within limited time constraints.
Effectiveness: High
Demonstrative Examples
Example 1
The following code could be for a social networking application in
which each user's profile information is stored in a separate file. All
files are stored in a single directory.
While the programmer intends to access files such as
"/users/cwe/profiles/alice" or "/users/cwe/profiles/bob", there is no
verification of the incoming user parameter. An attacker could provide a
string such as:
(Attack)
../../../etc/passwd
The program would generate a profile pathname like this:
(Result)
/users/cwe/profiles/../../../etc/passwd
When the file is opened, the operating system resolves the "../"
during path canonicalization and actually accesses this file:
(Result)
/etc/passwd
As a result, the attacker could read the entire text of the password
file.
Notice how this code also contains an error message information leak (CWE-209) if the user parameter does not produce a file that exists: the full pathname is provided. Because of the lack of output encoding of the file that is retrieved, there might also be a cross-site scripting problem (CWE-79) if profile contains any HTML, but other code would need to be examined.
Example 2
In the example below, the path to a dictionary file is read from a
system property and used to initialize a File object.
However, the path is not validated or modified to prevent it from
containing relative or absolute path sequences before creating the File
object. This allows anyone who can control the system property to
determine what file is used. Ideally, the path should be resolved
relative to some kind of application or user home directory.
Example 3
The following code takes untrusted input and uses a regular
expression to filter "../" from the input. It then appends this result to
the /home/user/ directory and attempts to read the file in the final
resulting path.
(Bad Code)
Example
Language: Perl
my $Username = GetUntrustedInput();
$Username =~ s/\.\.\///;
my $filename = "/home/user/" . $Username;
ReadAndSendFile($filename);
Since the regular expression does not have the /g global match
modifier, it only removes the first instance of "../" it comes across.
So an input value such as:
(Attack)
../../../etc/passwd
will have the first "../" stripped, resulting in:
(Result)
../../etc/passwd
This value is then concatenated with the /home/user/ directory:
(Result)
/home/user/../../etc/passwd
which causes the /etc/passwd file to be retrieved once the operating system has resolved the ../ sequences in the pathname. This leads to relative path traversal (CWE-23).
Example 4
The following code attempts to validate a given input path by
checking it against a white list and once validated delete the given file.
In this specific case, the path is considered valid if it starts with the
string "/safe_dir/".
(Bad Code)
Example
Language: Java
String path = getInputPath();
if (path.startsWith("/safe_dir/"))
{
File f = new File(path);
f.delete()
}
An attacker could provide an input such as this:
(Attack)
/safe_dir/../important.dat
The software assumes that the path is valid because it starts with the
"/safe_path/" sequence, but the "../" sequence will cause the program to
delete the important.dat file in the parent directory
Example 5
The following code demonstrates the unrestricted upload of a file
with a Java servlet and a path traversal vulnerability. The HTML code is the
same as in the previous example with the action attribute of the form
sending the upload file request to the Java servlet instead of the PHP
code.
When submitted the Java servlet's doPost method will receive the
request, extract the name of the file from the Http request header, read
the file contents from the request and output the file to the local
upload directory.
(Bad Code)
Example
Language: Java
public class FileUploadServlet extends HttpServlet {
BufferedWriter bw = new BufferedWriter(new
FileWriter(uploadLocation+filename, true));
for (String line; (line=br.readLine())!=null; )
{
if (line.indexOf(boundary) == -1) {
bw.write(line);
bw.newLine();
bw.flush();
}
} //end of for loop
bw.close();
} catch (IOException ex) {...}
// output successful upload response HTML
page
}
// output unsuccessful upload response HTML
page
else
{...}
}
...
}
This code does not check the filename that is provided in the header, so an attacker can use "../" sequences to write to files outside of the intended directory. Depending on the executing environment, the attacker may be able to specify arbitrary files to write to, leading to a wide variety of consequences, from code execution, XSS (CWE-79), or system crash.
Also, this code does not perform a check on the type of the file being uploaded. This could allow an attacker to upload any executable file or other file with malicious code (CWE-434).
chain: library file sends a redirect if it is
directly requested but continues to execute, allowing remote file inclusion
and path traversal.
Potential Mitigations
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.
When validating filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a whitelist of allowable file extensions, which will help to avoid CWE-434.
Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a blacklist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
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.
Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes:
realpath() in C
getCanonicalPath() in Java
GetFullPath() in ASP.NET
realpath() or abs_path() in Perl
realpath() in PHP
Phase: Architecture and Design
Strategy: Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to
occur or provides constructs that make this weakness easier to
avoid.
Phase: Operation
Strategy: Firewall
Use an application firewall that can detect attacks against this
weakness. It can be beneficial in cases in which the code cannot be
fixed (because it is controlled by a third party), as an emergency
prevention measure while more comprehensive software assurance measures
are applied, or to provide defense in depth.
Effectiveness: Moderate
An application firewall might not cover all possible input vectors. In
addition, attack techniques might be available to bypass the protection
mechanism, such as using malformed inputs that can still be processed by
the component that receives those inputs. Depending on functionality, an
application firewall might inadvertently reject or modify legitimate
requests. Finally, some manual effort may be required for
customization.
Phases: Architecture and Design; Operation
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.22.5]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Phase: Architecture and Design
Strategy: Enforcement by Conversion
When the set of acceptable objects, such as filenames or URLs, is
limited or known, create a mapping from a set of fixed input values
(such as numeric IDs) to the actual filenames or URLs, and reject all
other inputs.
For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [R.22.3] provide this capability.
Phases: Architecture and Design; Operation
Strategy: Sandbox or Jail
Run the code in a "jail" or similar sandbox environment that enforces
strict boundaries between the process and the operating system. This may
effectively restrict which files can be accessed in a particular
directory or which commands can be executed by the software.
OS-level examples include the Unix chroot jail, AppArmor, and SELinux.
In general, managed code may provide some protection. For example,
java.io.FilePermission in the Java SecurityManager allows the software
to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to
the operating system; the rest of the application may still be subject
to compromise.
Be careful to avoid CWE-243 and other weaknesses related to jails.
Effectiveness: Limited
The effectiveness of this mitigation depends on the prevention
capabilities of the specific sandbox or jail being used and might only
help to reduce the scope of an attack, such as restricting the attacker
to certain system calls or limiting the portion of the file system that
can be accessed.
Phases: Architecture and Design; Operation
Strategy: Identify and Reduce Attack Surface
Store library, include, and utility files outside of the web document
root, if possible. Otherwise, store them in a separate directory and use
the web server's access control capabilities to prevent attackers from
directly requesting them. One common practice is to define a fixed
constant in each calling program, then check for the existence of the
constant in the library/include file; if the constant does not exist,
then the file was directly requested, and it can exit
immediately.
This significantly reduces the chance of an attacker being able to
bypass any protection mechanisms that are in the base program but not in
the include files. It will also reduce the attack surface.
Phase: Implementation
Ensure that error messages only contain minimal details that are
useful to the intended audience, and nobody else. The messages need to
strike the balance between being too cryptic and not being cryptic
enough. They should not necessarily reveal the methods that were used to
determine the error. Such detailed information can be used to refine the
original attack to increase the chances of success.
If errors must be tracked in some detail, capture them in log messages
- but consider what could occur if the log messages can be viewed by
attackers. Avoid recording highly sensitive information such as
passwords in any form. Avoid inconsistent messaging that might
accidentally tip off an attacker about internal state, such as whether a
username is valid or not.
In the context of path traversal, error messages which disclose path
information can help attackers craft the appropriate attack strings to
move through the file system hierarchy.
Phases: Operation; Implementation
Strategy: Environment Hardening
When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
Other Notes
Incomplete diagnosis or reporting of vulnerabilities can make it difficult
to know which variant is affected. For example, a researcher might say that
"..\" is vulnerable, but not test "../" which may also be vulnerable.
Any combination of the items below can provide its own variant, e.g.
"//../" is not listed (CVE-2004-0325).
Weakness Ordinalities
Ordinality
Description
Primary
(where
the weakness exists independent of other weaknesses)
Resultant
(where
the weakness is typically related to the presence of some other
weaknesses)
Pathname equivalence can be regarded as a type of canonicalization
error.
Some pathname equivalence issues are not directly related to directory
traversal, rather are used to bypass security-relevant checks for whether a
file/directory can be accessed by the attacker (e.g. a trailing "/" on a
filename could bypass access rules that don't expect a trailing /, causing a
server to provide the file when it normally would not).
Research Gaps
Many variants of path traversal attacks are probably under-studied with respect to root cause. CWE-790 and CWE-182 begin to cover part of this gap.
Affected Resources
File/Directory
Relevant Properties
Equivalence
Functional Areas
File processing
Causal Nature
Explicit
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
PLOVER
Path Traversal
OWASP Top Ten 2007
A4
CWE_More_Specific
Insecure Direct Object Reference
OWASP Top Ten 2004
A2
CWE_More_Specific
Broken Access Control
CERT C Secure Coding
FIO02-C
Canonicalize path names originating from untrusted
sources
WASC
33
Path Traversal
CERT C++ Secure Coding
FIO02-CPP
Canonicalize path names originating from untrusted
sources
[R.22.1] [REF-11] M. Howard and
D. LeBlanc. "Writing Secure Code". Chapter 11, "Directory Traversal and Using Parent Paths (..)"
Page 370. 2nd Edition. Microsoft. 2002.
[R.22.6] [REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Filenames and Paths", Page
503.. 1st Edition. Addison Wesley. 2006.
Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Definition in a New Window
Weakness ID: 95 (Weakness Base)
Status: Incomplete
Description
Description Summary
The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
Extended Description
This may allow an attacker to execute arbitrary code, or at least modify what code can be executed.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
Java
Javascript
Python
Perl
PHP
Ruby
Interpreted Languages
Modes of Introduction
This weakness is prevalent in handler/dispatch procedures that might want
to invoke a large number of functions, or set a large number of
variables.
Common Consequences
Scope
Effect
Confidentiality
Technical Impact: Read files or
directories; Read application
data
The injected code could access restricted data / files.
Access Control
Technical Impact: Bypass protection
mechanism
In some cases, injectable code controls authentication; this may lead
to a remote vulnerability.
Access Control
Technical Impact: Gain privileges / assume
identity
Injected code can access resources that the attacker is directly
prevented from accessing.
Integrity
Confidentiality
Availability
Other
Technical Impact: Execute unauthorized code or
commands
Code injection attacks can lead to loss of data integrity in nearly
all cases as the control-plane data injected is always incidental to
data recall or writing. Additionally, code injection can often result in
the execution of arbitrary code.
Non-Repudiation
Technical Impact: Hide activities
Often the actions performed by injected control code are
unlogged.
Likelihood of Exploit
Medium
Demonstrative Examples
Example 1
edit-config.pl: This CGI script is used to modify settings in a
configuration file.
(Bad Code)
Example
Language: Perl
use CGI qw(:standard);
sub config_file_add_key {
my ($fname, $key, $arg) = @_;
# code to add a field/key to a file goes here
}
sub config_file_set_key {
my ($fname, $key, $arg) = @_;
# code to set key to a particular file goes here
}
sub config_file_delete_key {
my ($fname, $key, $arg) = @_;
# code to delete key from a particular file goes
here
}
sub handleConfigAction {
my ($fname, $action) = @_;
my $key = param('key');
my $val = param('val');
# this is super-efficient code, especially if you have to
invoke
# any one of dozens of different functions!
my $code = "config_file_$action_key(\$fname, \$key,
\$val);";
eval($code);
}
$configfile = "/home/cwe/config.txt";
print header;
if (defined(param('action'))) {
handleConfigAction($configfile, param('action'));
}
else {
print "No action specified!\n";
}
The script intends to take the 'action' parameter and invoke one of a
variety of functions based on the value of that parameter -
config_file_add_key(), config_file_set_key(), or
config_file_delete_key(). It could set up a conditional to invoke each
function separately, but eval() is a powerful way of doing the same
thing in fewer lines of code, especially when a large number of
functions or variables are involved. Unfortunately, in this case, the
attacker can provide other values in the action parameter, such
as:
(Attack)
add_key(",","); system("/bin/ls");
This would produce the following string in handleConfigAction():
(Result)
config_file_add_key(",","); system("/bin/ls");
Any arbitrary Perl code could be added after the attacker has "closed
off" the construction of the original function call, in order to prevent
parsing errors from causing the malicious eval() to fail before the
attacker's payload is activated. This particular manipulation would fail
after the system() call, because the "_key(\$fname, \$key, \$val)"
portion of the string would cause an error, but this is irrelevant to
the attack because the payload has already been activated.
chain: Resultant eval injection. An invalid value
prevents initialization of variables, which can be modified by attacker and
later injected into PHP eval statement.
Chain: Execution after redirect triggers eval
injection.
Potential Mitigations
Phases: Architecture and Design; Implementation
If possible, refactor your code so that it does not need to use eval()
at all.
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
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.
Consider performing repeated canonicalization until your input does
not change any more. This will avoid double-decoding and similar
scenarios, but it might inadvertently modify inputs that are allowed to
contain properly-encoded dangerous content.
Other Notes
Factors: special character errors can play a role in increasing the
variety of code that can be injected, although some vulnerabilities do not
require special characters at all, e.g. when a single function without
arguments can be referenced and a terminator character is not
necessary.
Weakness Ordinalities
Ordinality
Description
Primary
(where
the weakness exists independent of other weaknesses)
This issue is probably under-reported. Most relevant CVEs have been for
Perl and PHP, but eval injection applies to most interpreted languages.
Javascript eval injection is likely to be heavily under-reported.
[REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 18, "Inline Evaluation", Page
1095.. 1st Edition. Addison Wesley. 2006.
Improper Neutralization of HTTP Headers for Scripting Syntax
Definition in a New Window
Weakness ID: 644 (Weakness Variant)
Status: Incomplete
Description
Description Summary
The application does not neutralize or incorrectly neutralizes web scripting syntax in HTTP headers that can be used by web browser components that can process raw headers, such as Flash.
Extended Description
An attacker may be able to conduct cross-site scripting and other attacks against users who have these components enabled.
If an application does not neutralize user controlled data being placed in the header of an HTTP response coming from the server, the header may contain a script that will get executed in the client's browser context, potentially resulting in a cross site scripting vulnerability or possibly an HTTP response splitting attack. It is important to carefully control data that is being placed both in HTTP response header and in the HTTP response body to ensure that no scripting syntax is present, taking various encodings into account.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Integrity
Confidentiality
Availability
Technical Impact: Execute unauthorized code or
commands
Run arbitrary code.
Confidentiality
Technical Impact: Read application
data
Attackers may be able to obtain sensitive information.
Likelihood of Exploit
High
Enabling Factors for Exploitation
Script execution functionality is enabled in the user's browser.
Demonstrative Examples
Example 1
In the following Java example, user-controlled data is added to the
HTTP headers and returned to the client. Given that the data is not subject
to neutralization, a malicious user may be able to inject dangerous
scripting tags that will lead to script execution in the client
browser.
Web server does not remove the Expect header from
an HTTP request when it is reflected back in an error message, allowing a
Flash SWF file to perform XSS attacks.
Potential Mitigations
Phase: Architecture and Design
Perform output validation in order to filter/escape/encode unsafe data
that is being passed from the server in an HTTP response header.
Phase: Architecture and Design
Disable script execution functionality in the clients' browser.
View Data
