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

Difference between revisions of "XML Security Cheat Sheet"

From OWASP
Jump to: navigation, search
(Malformed XML Documents)
(More Time Required)
Line 30: Line 30:
 
* Parser limitation: Parsers may be limited to processing no more than a certain amount of certain data types. Maximum limits for elements, attributes, or entities may be set by default or by the developers. For example, the Java API for XML processing (JAXP) limits each element to no more than 10,000 attributes3.
 
* Parser limitation: Parsers may be limited to processing no more than a certain amount of certain data types. Maximum limits for elements, attributes, or entities may be set by default or by the developers. For example, the Java API for XML processing (JAXP) limits each element to no more than 10,000 attributes3.
 
* Architecture: The amount of computational resources available to the XML parser.
 
* Architecture: The amount of computational resources available to the XML parser.
 +
 +
Apache Xerces-J4 XML may serve as an example for this type of vulnerability; in this case, malformed data caused the XML parser:
 +
 +
<i>...to 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.
 +
 +
== Recommendation ==
 +
 +
To avoid this attack, you must confirm that your version of the XML processor does not take additional time to process malformed documents.

Revision as of 08:15, 11 December 2016

Introduction

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.

Authors and Primary Editors

Fernando Arnaboldi

Malformed XML Documents

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, 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. Without thorough testing, applications can be susceptible to vulnerabilities when supplied with malformed documents. Developers may not consider all of the potential types of inputs when designing software, since this is something normally found during the testing phase of a product.

In this example of a simple malformed document, the final ending tag is inconclusive:

<element>
 Some content
</element

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. The following are vulnerabilities related to malformed XML documents:

(enter table data here)

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 consumption2 attack to take advantage of the greater processing time to cause a Denial of Service (DoS). The following variables should be analyzed when exploring this behavior:

  • Parser inner workings: Each parser has its own particularities, which may make them more or less susceptible to malformed documents, thus requiring more time.
  • Document size: Processing a large well-formed document requires more time than doing the same for a smaller well-formed document. If the parser is susceptible, this also applies to malformed documents.
  • Parser limitation: Parsers may be limited to processing no more than a certain amount of certain data types. Maximum limits for elements, attributes, or entities may be set by default or by the developers. For example, the Java API for XML processing (JAXP) limits each element to no more than 10,000 attributes3.
  • Architecture: The amount of computational resources available to the XML parser.

Apache Xerces-J4 XML may serve as an example for this type of vulnerability; in this case, malformed data caused the XML parser:

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

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.