The software does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system. Within XML, special elements could include reserved words or characters such as "<", ">", """, and "&", which could then be used to add new data or modify XML syntax. 1000 699 Weakness ChildOf 74 629 Category ChildOf 713 711 Category ChildOf 727 809 Category ChildOf 810 888 Category ChildOf 896 The description for this entry is generally applicable to XML, but the name includes "blind XPath injection" which is more closely associated with CWE-643. Therefore this entry might need to be deprecated or converted to a general category - although injection into raw XML is not covered by CWE-643 or CWE-652. Architecture and Design Implementation Confidentiality Integrity Availability Execute unauthorized code or commands Read application data Modify application data Implementation 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. In vulnerability theory terms, this is a representation-specific case of a Data/Directive Boundary Error. Under-reported. This is likely found regularly by third party code auditors, but there are very few publicly reported examples. Amit Klein Blind XPath Injection 2004-05-19 http://www.modsecurity.org/archive/amit/blind-xpath-injection.pdf Mark Dowd John McDonald Justin Schuh The Art of Software Security Assessment Chapter 17, "XML Injection", Page 1069. 1st Edition Addison Wesley 2006 XML injection (aka Blind Xpath injection) Injection Flaws A2 CWE_More_Specific Injection Flaws A6 CWE_More_Specific XML Injection 23 83 PLOVER Eric Dalci Cigital 2008-07-01 updated Time_of_Introduction Veracode 2008-08-15 Suggested OWASP Top Ten 2004 mapping CWE Content Team MITRE 2008-09-08 updated Relationships, Other_Notes, Taxonomy_Mappings CWE Content Team MITRE 2008-10-14 updated Maintenance_Notes, Other_Notes, Theoretical_Notes CWE Content Team MITRE 2010-02-16 updated Taxonomy_Mappings CWE Content Team MITRE 2010-06-21 updated Description, Relationships CWE Content Team MITRE 2011-06-01 updated Common_Consequences CWE Content Team MITRE 2012-05-11 updated References, Relationships CWE Content Team MITRE 2012-10-30 updated Potential_Mitigations