Mobile Application Bounty Practice: SQL Injection Principles, Vulnerability Discovery and…

This article primarily shares an experience in exploiting SQL injection vulnerabilities in mobile app applications, focusing on the current environment and the various ways SQL injection can still be exploited along with its principles. It then goes on to share my approach to SQL injection exploitation and some methods to bypass Web Application Firewalls (WAF) for SQL injection through a practical exploitation process.

Before we begin, let’s briefly introduce the causes of SQL injection and the potential entry points for injections. We will use the following request as an example:

https://demo.com/order/list?name=xxxx&page=1&size=20&orderBy=createdAt

In my view, this URL has a certain probability of having an SQL injection vulnerability. Why do I say that? Let’s first look at how a service converts an HTTP request into an SQL query from a developer’s perspective.

Note: All examples will use the MySQL database, which is currently the most widely used database in internet companies.

Under normal circumstances, requests for querying lists will include two parts: query conditions and pagination parameters, corresponding to the keys above, such as key=xxx and page=1&size=20, which determine what we need to filter data based on and how many data entries we need to return. Converting them into SQL might look like this:

This query retrieves users whose name equals xxxxx and returns data entries from the 0th to the 20th.

However, the query conditions and pagination are passed from the front end, which means they are variables. Therefore, our SQL also needs to dynamically change based on these two variables. In ancient times, it might have been directly implemented using string concatenation, like this:

This is full of injection points. For example, if the name parameter is changed to `’ or 1=1 — `, the entire SQL becomes:

But this is an implementation method from a long time ago. This method actually concatenates the SQL within the code and then passes it to the database for execution. The database receives a complete SQL and runs it directly.

Note: Most products nowadays are unlikely to use string concatenation; instead, they use SQL-prepared statements.

What is SQL prepared statements? Simply put, it means I provide a SQL template with placeholders to the DB, and the corresponding parameters are separately passed to the database. This way, the database compiles the SQL based on the template and only inserts the parameters when it needs to execute, so it’s impossible to modify the corresponding syntax tree through parameters, and there will be no injections.

For a more detailed understanding, you can look into the execution process of MySQL. The original purpose of prepared statements was for performance.

For example, using prepared statements for the above SQL would look like this:

When executing in MySQL, it actually passes the prepared SQL and the corresponding parameter list, like this:

Why do we say that the sorting field might have injection points? For example, with the addition of a sorting field, the SQL would be like this:

However, MySQL stipulates that parameter markers in prepared statements can only be used where data values should appear and cannot be used for SQL keywords, identifiers, etc.

So the table field after `order by` cannot be used. At this point, string concatenation must be used, like this:

No matter what framework is used, such as Java’s Mybatis, which uses ${} instead of #{}, the essence is the same; it replaces prepared statement placeholders with string concatenation.

If the development is not rigorous and directly uses the string passed back from the front end, then this becomes an SQL injection point.

So, back to our discovery process, when I was auditing the source code of a certain Android app, I would try to search globally for sorting fields to check for query interfaces with sorting conditions, such as order_by, sort_by, sort, etc. This time I was fortunate to find some query interfaces with sortBy parameters:

Now we can try to see if there is an injection point. First, we try to inject with a single quote and find an error, indicating a server exception.

This could be due to the server filtering special characters, or it could be that the injection was successful and an exception was executed. But in any case, it at least indicates one thing: even if there is an SQL injection point, there is no feedback.

At this time, I tried to inject the rand() function to see if the data is returned, and if the returned data has a change in order.

We changed the query condition to orderBy=rand(), and found that the data would return normally, and after multiple queries, we found that its order was changing! This is a good start, meaning that the injection point exists, and there are prerequisites for blind injection.

Continuing, at this time, we can use rand(1=1) and rand(1=2) to make the interface return data in different orders, and we can use the differences in sorting to use boolean blind injection.

It can be observed that the IDs of the first data entries are different under the sorting conditions of true and false.

Next, we will use the following boolean blind injection payload to perform a brute-force attack to extract the database name:

The payload mentioned is indeed straightforward. Here’s how it works in the context of a boolean blind SQL injection:

① We utilize the database() function to retrieve the name of the current database. Then, we truncate it to obtain the first character using the substr() function. We then check if the ASCII value of this character is greater than 65, which corresponds to the uppercase letter ‘A’.

② If the ASCII value is greater than 65, it implies that the first character of the database name is not ‘A’, and the expression will return true, allowing us to continue our traversal. We keep iterating through the alphabet until the expression returns false, indicating that we have found the first character of the database name.

The order of the list returned by the interface can be used to determine whether the result of the expression is true or false.

However, unfortunately, we found that there was a WAF on the server side during our injection attempts, and this parameter was being blocked. After several attempts, we discovered that the WAF filters out commas, but we can bypass the WAF by replacing commas with spaces. The final blind SQL injection payload for the database name is as follows:

URL encoded as follows:

With the available complete payload, we can implement a simple Python script to accomplish the brute-force attack on the database name that we mentioned earlier, which we will skip over here.

Here are several simple and easy-to-implement yet highly effective measures to address SQL injection.

For most ordinary parameters, we must strictly adhere to security defense measures and use parameterized queries, which is to say, we use placeholders for parameter transmission. This is the most effective defense against SQL injection, bar none. As we mentioned earlier, parameterized queries ensure that input values are not interpreted as SQL code but are passed as parameters.

For scenarios where parameterized queries cannot be used, we should strictly limit user input content. The best approach is to use a whitelist. For example, the vulnerability we encountered earlier could be well defended against by filtering user-inputted sorting fields with a whitelist.

For all exceptional scenarios, it is necessary to handle exceptions on the server side and return readable error messages, especially database exceptions. This is also one of the effective means to increase the cost for attackers to perform SQL injection.

As one of the most effective modern security defenses, WAF can very effectively help us filter out most SQL injection attacks. Moreover, WAFs are generally evolving, which will increasingly raise the cost for attackers to carry out SQL injection.