|
Weakness ID: 91
Vulnerability Mapping:
ALLOWED
This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review
(with careful review of mapping notes)
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. |
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
| Impact | Details |
|---|---|
|
Execute Unauthorized Code or Commands; Read Application Data; Modify Application Data |
Scope: Confidentiality, Integrity, Availability |
| Phase(s) | Mitigation |
|---|---|
|
Implementation |
Strategy: Input Validation 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. |
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (View-1000)
| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf |
|
74 | Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') |
| ParentOf |
|
643 | Improper Neutralization of Data within XPath Expressions ('XPath Injection') |
| ParentOf |
|
652 | Improper Neutralization of Data within XQuery Expressions ('XQuery Injection') |
Relevant to the view "Software Development" (View-699)
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf |
|
137 | Data Neutralization Issues |
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf |
|
74 | Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') |
Relevant to the view "Architectural Concepts" (View-1008)
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf |
|
1019 | Validate Inputs |
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
| Phase | Note |
|---|---|
| Implementation | REALIZATION: This weakness is caused during implementation of an architectural security tactic. |
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
| Languages |
Class: Not Language-Specific (Undetermined Prevalence) |
| Ordinality | Description |
|---|---|
|
Primary
|
(where the weakness exists independent of other weaknesses)
|
| Method | Details |
|---|---|
|
Automated Static Analysis |
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Effectiveness: High |
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | 713 | OWASP Top Ten 2007 Category A2 - Injection Flaws | |
| MemberOf | 727 | OWASP Top Ten 2004 Category A6 - Injection Flaws | |
| MemberOf | 810 | OWASP Top Ten 2010 Category A1 - Injection | |
| MemberOf | 929 | OWASP Top Ten 2013 Category A1 - Injection | |
| MemberOf | 990 | SFP Secondary Cluster: Tainted Input to Command | |
| MemberOf | 1027 | OWASP Top Ten 2017 Category A1 - Injection | |
| MemberOf | 1308 | CISQ Quality Measures - Security | |
| MemberOf | 1340 | CISQ Data Protection Measures | |
| MemberOf | 1347 | OWASP Top Ten 2021 Category A03:2021 - Injection | |
| MemberOf | 1409 | Comprehensive Categorization: Injection | |
| MemberOf | 1440 | OWASP Top Ten 2025 Category A05:2025 - Injection |
| Usage |
ALLOWED-WITH-REVIEW
(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
|
||||
| Reason | Acceptable-Use | ||||
|
Rationale |
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. | ||||
|
Comments |
This weakness might be confused with other weaknesses such as XXE. 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. | ||||
|
Suggestions |
|
Theoretical
Research Gap
Maintenance
| Mapped Taxonomy Name | Node ID | Fit | Mapped Node Name |
|---|---|---|---|
| PLOVER | XML injection (aka Blind Xpath injection) | ||
| OWASP Top Ten 2007 | A2 | CWE More Specific | Injection Flaws |
| OWASP Top Ten 2004 | A6 | CWE More Specific | Injection Flaws |
| WASC | 23 | XML Injection | |
| Software Fault Patterns | SFP24 | Tainted input to command |
| [REF-882] |
Amit Klein. "Blind XPath Injection". 2004-05-19.
<https://dl.packetstormsecurity.net/papers/bypass/Blind_XPath_Injection_20040518.pdf>. (URL validated: 2023-04-07) |
| [REF-62] | Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "XML Injection", Page 1069. 1st Edition. Addison Wesley. 2006. |
|
Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2026, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation. |
||
