It is impossible to protect APIs unless you take a deep dive into the protocols implemented over the standard HTTP. Most security tools are not protecting data where itâs most vulnerable, inside the XML schema itself. These encoding attacks are going unflagged by many application platforms, despite topline security tools and techniques they believe protect APIs. The problem is in the code and the relative inability to notice what malicious attack may be hiding inside at a fundamental level.
You may already know that whitehat researchers have used data protocol-level encodings to avoid WAF filtration. This bypass hacking technique is no secret. Hackers can use a JSON Unicode escape sequences to bypass WAFs. Most WAFs leave companies vulnerable and open to stealthy cyberattacks hide in API data. Unicode escape sequences can pass through simple RegExp-based signatures, bypassing JSON API protection. But itâs not just a problem for JSON.
Now, we want to describe different encoding techniques for XML/SOAP APIs as a continuation of that research. We can show why you absolutely cannot have API protections without dealing with specific data encoding protocols.
XML Encoding Security Issues
Like JSON, XML allows the encoding of data in different ways, such as built-in entities. This can leave APIs vulnerable to cyberattacks. Here are three ways XML variation can obscure code, leaving it unmonitored (even though it may seem covered). The first two are comparably easier to protect against. The third mechanism that can be used to hide malicious code is more sophisticated and harder to protect against.
Letâs consider the following statement, as an example:
union select password from users--a-
If successfully executed, this statement would allow a hacker to gain access to the passwords of all the users on the system. Naturally, WAFs and other protection systems would try to block it.
A signature for this kind of attack would look for a string âunion select passwordâ in the XML encoded data stream.
Now, letâs see how that can be circumvented.
1. Internal Variables Replace Characters
An internal variable can be used to replace some characters in strings inside XML tags. For example, you could use â â instead of a space, like this:
â union select password from users--a-
In this case, the XML parser will easily replace the named entity, â â, with a space character. However, the signature for union + select will not detect the replacement.
2. HTML HEX-Codes
The second encoding option is using HTML HEX-codes, such as âUâ instead of âUâ character, like this:
âUnion select password from usersâââa-
Which is almost equal to u0085 encoding for JSON previously described in Bypassing WAFS with JSON Unicode Escape Sequences or our article on why WAFs miss attacks hiding in API data.
3. Is Your WAF Fully Compatible with XML Data Encoding?
The third obfuscation mechanism is the most complicated and dangerous one. Unlike the two other encoding options, this third mechanism requires the WAF to be fully compatible with XML data encoding to catch it. This evasion technique is based on XML-defined entities, which is almost equal to variables with defined values. This technique makes it possible to build any string inside XML tags using references for entities/variables defined earlier. Take a look:
<!DOCTYPE a [<!ENTITY u âuniâ>]><a>&u;on select password from usersâââa-</a>
In this example, a piece of the payload was defined at the beginning of the XML document as the âuâ variable used later inside <a> XML tag.
No regular expressions can be used to detect the replaced code. As explained by the Chomsky Hierachy, XML syntax is inherently not regular.
We have explained how grammar-based detection can bring the API parsing to the new level in a recent whitepaper Evolution of Real-Time Attack Detection.
Going Inside: Encoding Attack Block
Obfuscation mechanisms can be incredibly sophisticated, planting seeds that are imperceptible until a dangerous security problem or breach surfaces. Most security tools are not set up to detect the hidden code and block XML encoding attacks. Wallarm implements a full XML-compatible parser inside to block XML encoding attacks. It allows the protection of any SOAP, XMLRPC and other XML-based APIs out-of-the-box.
This screenshot shows how encoding attack block works:
This screenshot shows Wallarm solving for the custom entities-based evasion technique:
Cyberattackers can use your own code to infiltrate and change code completely undetected, bypassing standard API protections. Going deeper, by installing parsers inside, can strengthen the areas that are presently unpoliced by more superficial or traditional security tools.
If you enjoyed this article, take a look at our previous XML-related research in XXE That Can Bypass WAF Protection. Find more information about different XML encodings for entire documents.
Follow Wallarm Labsâ research on Medium.
#Cybersecurity #Hacker #Cyberattack #Whitehat
