XML Injection, SOAP Injection - Notes

==============================================================================

XML Injection

==============================================================================
XML is used extensively in web applications

• In Request & Responses to submit data & receive data from server.
• In Messages between back-end components
• AJAX mostly uses XML for communication with server.
• Browser extension components also use XML to communicate with server.
• Content type: text/xml

XML EXTERNAL ENTITY ATTACK ( XXE Injection )

Entity Reference:  

• Characters with special meaning in XML like "<" will generate an error as it is interpreted as the start of a new element. 
• To avoid errors, replace the "<" character with an entity reference (&lt;)
• Entity references always begin with an ampersand (&) and end with a semicolon (;)
• For < , >  the corresponding entities are     &lt;    &gt;
• XML allows CUSTOM ENTITIES to be defined at the start of XML document itself using DOCTYPE element.
• <!DOCTYPE note [ <!ENTITY testreference "referencevalue"> ]>
• &testreference; will be replaced by referencevalue

Vulnerability exists because 

• XML parsing libraries support the use of ENTITY REFERENCES.
• XML allows the use of EXTERNAL REFERENCES, whose values are fetched dynamically
• EXTERNAL ENTITY definitions use the URL Format & can refer to web URLs or local file.
• If the XML response contains an "External defined ENTITY", THEN the contents of specified URL or FILE are RETRIEVED & INCLUDED in the response.

ATTACKER simply specifies an external entity in his XML Request by adding or modifying DOCTYPE element.

•  SYSTEM keyword is used to specify an EXTERNAL ENTITY
•  URL may use also the    file:     protocol
• <!DOCTYPE note [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
• <!DOCTYPE note [ <!ENTITY xxe SYSTEM "http://www.foo.com/hack.txt"> ]>
• <foo>  &xxe;  </foo> 
• The contents of the file will replace      &xxe;

Consequences of XXE

• Attacker can use application as proxy to access external server as well as Internal resources and services
• Attacker can test for open ports on backend systems.
• Attacker can cause a DoS attack, by reading a file stream indefinitely.

==============================================================================

SOAP ( Simple Object Access Protocol) INJECTION

==============================================================================

SOAP INTRODUCTION

Web Service uses two methods to exchange data

1. SOAP (Simple Object Access Protocol)
2. REST (Representational State Transfer)

• SOAP uses HTTP protocol to transmit messages
• SOAP uses XML to represent the data  (Content-Type: application / soap+xml)
• Using user-supplied-data in SOAP messages can lead to vulnerabilities.
• Directly exposed web-services are worthy of vulnerability examination
• WSDL (Web Services Description Language) file describes the following

-How to call the web service
-What parameters it expects
-What data structure it returns

• Tools for testing WEB Service Testing - SoapUI

Web Service ( on the Left )

SOAP Request (on the Right)

SOAP INJECTION VULNERABILITY

• Vulnerability occurs because SOAP uses XML, and XML is an Interpreted Language.
• If the ATTACKER is able to inject METACHARACTERS like < > and / in a SOAP messages, then it can interfere with application's logic.

Injecting an additional <FundsCleared> True </FundsCleared>, in a bank application

• It may allow funds to be transferred even if there are no funds
• This Attack depends on how the application processes multiple elements with same TAG
• Inject has to be done in a way that preserves the XML Syntax

Preventing SOAP Injection

Implement BOUNDARY VALIDATION filters

• Filter at Application Boundary- when data is received from the USER
• Filter at SOAP service Boundary -, after the input data has been generated, or extracted from DB or processed from user supplied Input.

HTML Encode XML Metacharacters like < > / etc.

Attacking SOAP Service

To test if vulnerability exists >>>> Try inserting      </foo>   in each parameter, if you get an error, then input is being used in a SOAP service.

• SOAP Injection Vulnerability is difficult to detect
• SOAP Injection Vulnerability is harder to exploit as it needs knowledge of XML Structure, a verbose error message might help in this case. Else its pure guesswork.

Example ATTACK

Expected Request Format

<Transfer>

    <From>        1235 </From>

    <Amount>      1000 </Amount>

    <To>          54321</To>

</Transfer>

After Injection (Injected content in RED)

<Transfer>

    <From>        1235 </From>

    <Amount>      1000 </Amount>

    <FundsCleared>True </FundsCleared>

    <Amount>      1000 </Amount>

    <To>          54321</To>

</Transfer>

Request After getting processed by the application
(works if the application process the FIRST <FundsCleared> Tag it encounters)

<Transfer>

    <From>        1235 </From>

    <Amount>      1000 </Amount>

    <FundsCleared>True </FundsCleared>

    <Amount>      1000 </Amount>

    <FundsCleared>False</FundsCleared>

    <To>          54321</To>

</Transfer>

The Injected content Can include comments to comment out a part of the XML Request
<!-- Comment   -->

<Transfer>

    <From>        1235 </From>

    <Amount>      1000 </Amount>

    <FundsCleared>True </FundsCleared>

    <!--Amount>   1000 </Amount>

    <To>   --><To>54321</To>

</Transfer>

==============================================================================