Injecting into SOAP
The Simple Object Access Protocol (SOAP) is a message-based communications technology that uses the XML format to encapsulate data. It can be used to share information and transmit messages between systems, even if these run on different operating systems and architectures. Its primary use is in web services, and in the context of a browser-accessed web application, you are most likely to encounter SOAP in the communications that occur between back-end application components.
SOAP is often used in large-scale enterprise applications where individual tasks are performed by different computers to improve performance. It is also often found where a web application has been deployed as a front end to an existing application. In this situation, communications between different components may be implemented using SOAP to ensure modularity and interoperability.
Because XML is an interpreted language, SOAP is potentially vulnerable to code injection in a similar way as the other examples already described. XML elements are represented syntactically, using the metacharacters < > and / . If user-supplied data containing these characters is inserted directly into a SOAP message, an attacker may be able to interfere with the structure of the message and so interfere with the application’s logic or cause other undesirable effects. Consider a banking application in which a user initiates a funds transfer using an HTTP request like the following:
POST /transfer.asp HTTP/1.0
Host: wahh-bank.com
Content-Length: 65
FromAccount=18281008&Amount=1430&ToAccount=08447656&Submit=Submit
In the course of processing this request, the following SOAP message is sent between two of the application’s back-end components:
<soap:Envelope xmlns:soap=”http://www.w3.org/2001/12/soap-envelope”>
<soap:Body>
<pre:Add xmlns:pre=http://target/lists soap:encodingStyle=
”http://www.w3.org/2001/12/soap-encoding”>
<Account>
<FromAccount>18281008</FromAccount>
<Amount>1430</Amount>
<ClearedFunds>False</ClearedFunds>
<ToAccount>08447656</ToAccount>
</Account>
</pre:Add>
</soap:Body>
</soap:Envelope>
Note how the XML elements in the message correspond to the parameters in the HTTP request, and also the addition of the ClearedFunds element. At this point in the application’s logic, it has determined that there are insufficient funds available to perform the requested transfer, and has set the value of this element to False , with the result that the component which receives the SOAP message does not act upon it.
In this situation, there are various ways in which you could seek to inject into the SOAP message, and so interfere with the application’s logic. For example, submitting the following request will cause an additional ClearedFunds element to be inserted into the message before the original element (while preserving the SQL’s syntactic validity). If the application processes the first ClearedFunds element that it encounters, then you may succeed in performing a transfer when no funds are available:
POST /transfer.asp HTTP/1.0
Host: wahh-bank.com
Content-Length: 119
FromAccount=18281008&Amount=1430</Amount><ClearedFunds>True
</ClearedFunds><Amount>1430&ToAccount=08447656&Submit=Submit
If, on the other hand, the application processes the last ClearedFunds element that it encounters, you could inject a similar attack into the ToAccount parameter.
A different type of attack would be to use XML comments to remove part of the original SOAP message altogether, and replace the removed elements with your own. For example, the following request injects a ClearedFunds element via the Amount parameter, provides the opening tag for the ToAccount element, opens a comment, and closes the comment in the ToAccount parameter, thus preserving the syntactic validity of the XML:
POST /transfer.asp HTTP/1.0
Host: wahh-bank.com
Content-Length: 125
FromAccount=18281008&Amount=1430</Amount><ClearedFunds>True
</ClearedFunds><ToAccount><!–&ToAccount=–>08447656&Submit=Submit
A further type of attack would be to attempt to complete the entire SOAP message from within an injected parameter and comment out the remainder of the message. However, because the opening comment will not be matched by a closing comment, this attack produces strictly invalid XML, which will be rejected by many XML parsers:
POST /transfer.asp HTTP/1.0
Host: wahh-bank.com
FromAccount=18281008&Amount=1430</Amount<ClearedFunds>True</ClearedFunds<ToAccount>08447656</ToAccount></Account></pre:Add></soap:Body></soap:Envelope<!&Submit=Submit
Finding and Exploiting SOAP Injection
SOAP injection can be difficult to detect, because supplying XML metacharacters in a noncrafted way will break the format of the SOAP message, and this will often simply result in an uninformative error message. Nevertheless, the following steps can be used to detect SOAP injection vulnerabilities with a degree of reliability.
If SOAP injection is difficult to detect, then it can be even harder to exploit. In most situations, you will need to know the structure of the XML that surrounds your data, in order to supply crafted input which modifies the message without invalidating it. In all of the preceding tests, look for any error messages that reveal any details about the SOAP message being processed. If you are lucky, a verbose message will disclose the entire message, enabling you to construct crafted values to exploit the vulnerability. If you are unlucky, you may be restricted to pure guesswork, which is very unlikely to be successful.
Preventing SOAP Injection
SOAP injection can be prevented by employing boundary validation filters at any point where user-supplied data is inserted into a SOAP message. This should be performed both on data that has been immediately received from the user in the current request and on any data which has been persisted from earlier requests or generated from other processing that takes user data as input.
To prevent the attacks described, the application should HTML-encode any XML metacharacters appearing in user input. HTML-encoding involves replacing literal characters with their corresponding HTML entities. This ensures that the XML interpreter will treat them as part of the data value of the relevant element, and not as part of the structure of the message itself. The HTML-encodings of some common problematic characters are:
< <
> >
/ /
NEXT is..Injecting into XPath………………………,,,,,,,,,,,,,,,,,,,,,
