This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Difference between revisions of "XML Security Cheat Sheet"

Jump to: navigation, search
m (Point to the official site)
(42 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Introduction ==
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
Specifications for XML and XML schemas include multiple security flaws. At the same time, these specifications provide the tools required to protect XML applications. This provides a complex scenario for developers, and a fun environment for hackers. Even though we use XML schemas to define the security of XML documents, they can be used to perform a variety of attacks: file retrieval, server side request forgery, port scanning, or brute forcing. This talk will analyze how to infer new attack vectors by analyzing the current vulnerabilities, and how it is possible to affect common libraries and software. This cheatsheet will also provide recommendations for safe deployment of applications relying on XML.
The Cheat Sheet Series project has been moved to [ GitHub]!
=  Malformed XML Documents =
Please visit [ XML Security Cheat Sheet] to see the latest version of the cheat sheet.
The W3C XML specification defines a set of principles that XML documents must follow to be considered well formed. When a document violates any of these principles, it must be considered a fatal error and the data it contains is considered malformed. Multiple tactics will cause a malformed document: removing an ending tag, rearranging the order of elements into a nonsensical structure, introducing forbidden characters, and so on. The XML parser should stop execution once detecting a fatal error. The document shouldn’t undergo any additional processing, and the application should display an error message.
== More Time Required ==
A malformed document may affect the consumption of Central Processing Unit (CPU) resources. In certain scenarios, the amount of time required to process malformed documents may be greater than that required for well-formed documents. When this happens, an attacker may exploit an asymmetric resource consumption attack to take advantage of the greater processing time to cause a Denial of Service (DoS).
Apache Xerces-J XML may serve as an example for this type of vulnerability; in this case, malformed data caused the XML parser "<i> consume CPU resource for several minutes before the data [was] eventually rejected. This behavior can be used to launch a denial of service attack against any Java server application, which processes XML data supplied by remote users.</i>". An attacker could use this vulnerability in conjunction with an XML flood attack using multiple documents.
To avoid this attack, you must confirm that your version of the XML processor does not take additional time to process malformed documents.
== Applications Processing Malformed Data ==
Certain XML parsers have the ability to recover malformed documents. They can be instructed to try their best to return a valid tree with all the content that they can manage to parse, regardless of the document’s noncompliance with the specifications. Since there are no predefined rules for the recovery process, the approach and results may not always be the same. Using malformed documents might lead to unexpected issues related to data integrity.
The following three scenarios illustrate attack vectors a parser will analyze in recovery mode:
=== Malformed Document to Malformed Document Containing Unexpected Characters ===
According to the XML specification, the string -- (double-hyphen) must not occur within comments. Using the recovery mode of lxml and PHP, the following document will remain the same after being recovered:
  <!-- one
    <!-- another comment
  comment -->
=== Well-Formed Document to Well-Formed Document Normalized ===
Certain parsers may consider normalizing the contents of your CDATA6 sections. This means that they will update the special characters contained in the CDATA section to contain the safe versions of these characters even though is not required:
Normalization of a CDATA section is not a common rule among parsers. Libxml could transform this document to its canonical version, but although well formed, its contents may be considered malformed depending on the situation:
=Authors and Primary Editors=
[mailto:fernando.[email protected] Fernando Arnaboldi]

Latest revision as of 14:32, 15 July 2019


The Cheat Sheet Series project has been moved to GitHub!

Please visit XML Security Cheat Sheet to see the latest version of the cheat sheet.