|
|
| (39 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | == Introduction == | + | __NOTOC__ |
| | + | <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 [https://github.com/OWASP/CheatSheetSeries GitHub]! |
| | | | |
| − | = Malformed XML Documents =
| + | Please visit [https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html 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).
| |
| − | | |
| − | To analyze the likelihood of this attack, analyze the time taken by a regular XML document vs a malformed XML document. Then, consider how an attacker could use this vulnerability in conjunction with an XML flood attack using multiple documents.
| |
| − | | |
| − | ;Recommendation
| |
| − | | |
| − | 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 ===
| |
| − | 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:
| |
| − | | |
| − | <pre><element>
| |
| − | <!-- one
| |
| − | <!-- another comment
| |
| − | comment -->
| |
| − | </element></pre>
| |
| − | | |
| − | === 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:
| |
| − | <pre><element>
| |
| − | <![CDATA[<script>a=1;</script>]]>
| |
| − | </element></pre>
| |
| − | | |
| − | 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:
| |
| − | <pre><element>
| |
| − | &lt;script&gt;a=1;&lt;/script&gt;
| |
| − | </element></pre>
| |
| − | | |
| − | ;Recommendation
| |
| − | If it is not possible to process only well-formed documents, take into consideration that the final results could be unreliable. To avoid this attack completely, you must not recover or process malformed documents.
| |
| − | | |
| − | == Coersive Parsing ==
| |
| − | A coercive attack in XML involves parsing deeply nested XML documents without their corresponding ending tags. The idea is to make the victim use up—and eventually deplete—the machine’s resources and cause a denial of service on the target.
| |
| − | Reports of a DoS attack in Firefox 3.67 included the use of 30,000 open XML elements without their corresponding ending tags. Removing the closing tags simplifies the attack since it requires only half of the size of a well-formed document to accomplish the same results. The number of tags being processed eventually caused a stack overflow. A simplified version of such a document would look like this:
| |
| − | <pre><A1>
| |
| − | <A2>
| |
| − | <A3>
| |
| − | ...
| |
| − | <A30000></pre>
| |
| − | | |
| − | ;Recommendation
| |
| − | To avoid this attack you must define a maximum number of items (elements, attributes, entities, etc.) to be processed by the parser. If possible, use an XML schema to validate the document structure.
| |
| − | | |
| − | == Violation of XML Specification Rules ==
| |
| − | Unexpected consequences may result from manipulating documents using parsers that do not follow W3C specifications. It may be possible to achieve crashes and/or code execution when the software does not properly verify how to handle incorrect XML structures. Feeding the software with fuzzed XML documents may expose this behavior.
| |
| − | | |
| − | ;Recommendation
| |
| − | To avoid this attack you must use an XML processor that follows W3C specifications. In addition, validate the contents of each element and attribute to process only valid values within predefined boundaries.
| |
| − | | |
| − | = Invalid XML Documents =
| |
| − | Attackers may introduce unexpected values in documents to take advantage of an application that does not verify whether the document contains a valid set of values. Schemas specify restrictions that help identify whether documents are valid. A valid document is well formed and complies with the restrictions of a schema, and more than one schema can be used to validate a document. These restrictions may appear in multiple files, either using a single schema language or relying on the strengths of the different schema languages.
| |
| − | | |
| − | == Document without Schema ==
| |
| − | Consider a bookseller that uses a web service through a web interface to make transactions. The XML document for transactions is composed of two elements: an id value related to an item and a certain price. The user may only introduce a certain id value using the web interface:
| |
| − | <pre><buy>
| |
| − | <id>123</id>
| |
| − | <price>10</price>
| |
| − | </buy></pre>
| |
| − | | |
| − | If there is no control on the document’s structure, the application could also process different well-formed messages with unintended consequences. The previous document could have contained additional tags to affect the behavior of the underlying application processing its contents:
| |
| − | <pre><buy>
| |
| − | <id>123</id><price>0</price><id></id>
| |
| − | <price>10</price>
| |
| − | </buy></pre>
| |
| − | | |
| − | Notice again how the value 123 is supplied as an id, but now the document includes additional opening and closing tags. The attacker closes the id element and sets a bogus price element to the value 0. The final step to keep the structure well-formed is to add one opening id. After this, the application adds the closing tag for id and sets the price to 10. If the application processes only the first values provided for the id and the value without performing any type of control on the structure, it could benefit the attacker by providing the ability to buy a book without actually paying for it.
| |
| − | | |
| − | ; Recommendation
| |
| − | Each XML document must have a precisely defined XML schema with every piece of information properly restricted to avoid problems of improper data validation.
| |
| − | | |
| − | == Unrestrictive Schema ==
| |
| − | Certain schemas don’t offer enough restrictions for the type of data that each element can receive. This is what normally happens when using DTD; it has a very limited set of possibilities compared to the type of restrictions that can be applied in XML documents. This could expose the application to undesired values within elements or attributes that would be easy to constrain when using other schema languages. In the following example, a person’s age is validated against an inline DTD schema:
| |
| − | <pre><!DOCTYPE person [
| |
| − | <!ELEMENT person (name, age)>
| |
| − | <!ELEMENT name (#PCDATA)>
| |
| − | <!ELEMENT age (#PCDATA)>
| |
| − | ]> | |
| − | <person>
| |
| − | <name>John Doe</name>
| |
| − | <age>11111..(1.000.000digits)..11111</age>
| |
| − | </person></pre>
| |
| − | | |
| − | The previous document contains an inline DTD with a root element named person. This element contains two elements in a specific order: name and then age. The element name is then defined to contain PCDATA as well as the element age. After this definition begins the well-formed and valid XML document. The element name contains an irrelevant value but the age element contains one million digits. Since there are no restrictions on the maximum size for the age element, this one-million-digit string could be sent to the server for this element. Typically this type of element should be restricted to contain no more than a certain amount of characters and constrained to a certain set of characters (for example, digits from 0 to 9, the + sign and the - sign).
| |
| − | If not properly restricted, applications may handle potentially invalid values contained in documents. Since it isn’t possible to indicate specific restrictions (a maximum length for the element name or a valid range for the element age), this type of schema increases the risk of affecting the integrity and availability of resources.
| |
| − | | |
| − | ;Recommendation
| |
| − | Use a schema language capable of properly restricting information.
| |
| − | | |
| − | =Authors and Primary Editors=
| |
| − | | |
| − | | |
