Détail du CWE-96

CWE-96

Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')
Draft
2006-07-19
00h00 +00:00
2023-06-29
00h00 +00:00
CWE Mitre.org
Notifications pour un CWE
Restez informé de toutes modifications pour un CWE spécifique.
Gestion des notifications

Nom: Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')

The product 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.

Informations générales

Modes d'introduction

Implementation : REALIZATION: This weakness is caused during implementation of an architectural security tactic.
Implementation : This issue is 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.

Plateformes applicables

Langue

Name: PHP (Undetermined)
Name: Perl (Undetermined)
Class: Interpreted (Undetermined)

Conséquences courantes

Portée Impact Probabilité
ConfidentialityRead Files or Directories, Read Application Data

Note: The injected code could access restricted data / files.
Access ControlBypass Protection Mechanism

Note: In some cases, injectable code controls authentication; this may lead to a remote vulnerability.
Access ControlGain Privileges or Assume Identity

Note: Injected code can access resources that the attacker is directly prevented from accessing.
Integrity
Confidentiality
Availability
Other		Execute Unauthorized Code or Commands

Note: 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-RepudiationHide Activities

Note: Often the actions performed by injected control code are unlogged.

Exemples observés

Références Description

CVE-2002-0495

Perl code directly injected into CGI library file from parameters to another CGI program.

CVE-2005-1876

Direct PHP code injection into supporting template file.

CVE-2005-1894

Direct code injection into PHP script that can be accessed by attacker.

CVE-2003-0395

PHP code from User-Agent HTTP header directly inserted into log file implemented as PHP script.

CVE-2007-6652

chain: execution after redirect allows non-administrator to perform static code injection.

Mesures d’atténuation potentielles

Phases : Implementation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list 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. This 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, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.


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

Notes de cartographie des vulnérabilités

Justification : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Commentaire : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Modèles d'attaque associés

CAPEC-ID Nom du modèle d'attaque
CAPEC-35 Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
CAPEC-73 User-Controlled Filename
An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.
CAPEC-77 Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.
CAPEC-81 Web Server Logs Tampering
Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.
CAPEC-85 AJAX Footprinting
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.

NotesNotes

"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.

Soumission

Nom Organisation Date Date de publication Version
PLOVER 2006-07-19 +00:00 2006-07-19 +00:00 Draft 3

Modifications

Nom Organisation Date Commentaire
Eric Dalci Cigital 2008-07-01 +00:00 updated Potential_Mitigations, Time_of_Introduction
CWE Content Team MITRE 2008-09-08 +00:00 updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
CWE Content Team MITRE 2009-05-27 +00:00 updated Description, Name
CWE Content Team MITRE 2010-04-05 +00:00 updated Description, Name
CWE Content Team MITRE 2010-06-21 +00:00 updated Potential_Mitigations
CWE Content Team MITRE 2011-06-01 +00:00 updated Common_Consequences
CWE Content Team MITRE 2012-05-11 +00:00 updated Common_Consequences, Demonstrative_Examples, Relationships
CWE Content Team MITRE 2012-10-30 +00:00 updated Potential_Mitigations
CWE Content Team MITRE 2013-02-21 +00:00 updated Observed_Examples
CWE Content Team MITRE 2014-06-23 +00:00 updated Enabling_Factors_for_Exploitation, Other_Notes, Relationship_Notes
CWE Content Team MITRE 2014-07-30 +00:00 updated Relationships, Taxonomy_Mappings
CWE Content Team MITRE 2017-05-03 +00:00 updated Related_Attack_Patterns
CWE Content Team MITRE 2017-11-08 +00:00 updated Affected_Resources, Applicable_Platforms, Causal_Nature, Demonstrative_Examples, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
CWE Content Team MITRE 2020-02-24 +00:00 updated Potential_Mitigations, Relationships, Taxonomy_Mappings
CWE Content Team MITRE 2020-06-25 +00:00 updated Potential_Mitigations
CWE Content Team MITRE 2021-03-15 +00:00 updated Demonstrative_Examples
CWE Content Team MITRE 2021-10-28 +00:00 updated Relationships
CWE Content Team MITRE 2022-10-13 +00:00 updated Relationships, Taxonomy_Mappings
CWE Content Team MITRE 2023-01-31 +00:00 updated Description
CWE Content Team MITRE 2023-04-27 +00:00 updated Modes_of_Introduction, Relationships, Time_of_Introduction
CWE Content Team MITRE 2023-06-29 +00:00 updated Mapping_Notes