7. SQLi in different contexts
SQLi in different contexts
So far, we have used the query string to inject our malicious SQL payload. However, we can perform SQLi attacks using any controllable input that is processed as a SQL query. For example, some websites take input in JSON or XML format and use this to query the database.
These different formats may provide different ways for us to obfuscate attacks that are otherwise blocked due to WAFs and other defence mechanisms. Weak implementations often look for common SQLi keywords within the request, so we may be able to bypass these filters by encoding or escaping characters in the prohibited keywords.
For example, the following XML-based SQLi uses an XML escape sequence to encode the s character in SELECT:
This will be decoded server-side before being passed to the SQL interpreter.
Lab: SQL injection with filter bypass via XML encoding
Objective: This lab contains a SQLi vulnerability in its stock check feature. The results from the query are returned in the application’s response, so you can use a UNION attack to retrieve data from other tables. The database contains a
userstable, which contains the usernames and passwords of registered users. To solve the lab, perform a SQLi attack to retrieve theadministratoruser’s credentials, then log in to their account.
Hint: A web application firewall (WAF) will block requests that contain obvious signs of a SQLi attack. You’ll need to find a way to obfuscate your malicious query to bypass this filter. We recommend using the Hackvertor extension to do this.
Let’s first get ready by installed the Hackvertor extension:
Now, let’s see how the stock request looks like:
The idea is to pass our SQLi UNION attack inside the XML part of the request:
As the lab description mentions, there is a WAF that block common keywords used in SQLi attacks. Thus, we will need to obfuscate our input:
The payload now works, so we can build our query and obtain the information required:
