Multistep SQL injection attacks: Operating principle and impact

First, let’s discuss the general multistep SQLi detection methodology, then examine built-in sqlmap functions that can be used to identify multistep SQLi, and finally write a wrapper to search for such injections.

How to search for multistep SQLi

Testing of multistep injections involves four main stages:

1. Preparation. At the preparation stage, data or objects are created: the injection will be performed either into them or using them. Example: creating a draft news article on a news portal (“Create draft” button) or creating a new letter (“Write letter” button);
2. Injection. At this stage, payload is directly added to the transmitted data. Example: saving a news article after editing;
3. Confirmation. At this stage, the creation of the object is confirmed. Example: confirming the publication of a news article; and 
4. Result. It’s assumed that there is a separate page where you can see the result of the injection. Example: web page containing the published news article.

At each stage, several requests can be sent, but their nature doesn’t change:

1. Requests prior to injection;
2. Request containing injection;
3. Requests after injection; and 
4. Checking the result.

Business logic of a specific app might include not all of these stages. For instance, the preparation stage can be absent: you create a news article without sending a separate request since a news article is created as soon as you start editing it.

Built-in sqlmap functions that can be used to exploit multistep SQLi

Built-in sqlmap functions make it possible to interact not only with the request containing payload, but also with requests sent before it and after it.

The main such functions are:

• tamper (handle payload);
• eval (change the main request); and 
• second-req/second-url (execute a request after the main one).

Sqlmap tamper

Purpose: modify payload prior to sending it by executing Python code.

Parameter:

Features:

• Ready-made tamper scripts are available; normally, they are located in /usr/share/sqlmap/tamper/;
• To view existing tamper scripts, use the command sqlmap --list-tampers; and 
• You can create your own tamper scripts in Python.

Can be used to:

• bypass WAF (see examples on GitHub); and 
• execute queries prior to sending the main sqlmap payload.

Sqlmap eval

Purpose: modify a request prior to sending it by executing Python code.

Parameter:

Features:

• Doesn’t have access to payload that will be injected. If the variable is replaced, payload would be lost;
• Modifies the request every time the main payload is sent (--second-req isn’t modified); and 
• Any part of the request can be modified, including URI.

Can be used to:

• bypass WAF (see an example on GitHub); and 
• execute queries prior to sending the main sqlmap payload.

Example with eval

To use eval, Python code is passed to the --eval parameter as a single-line command:

sqlmap … --eval="import time; title=time.time()"

Sqlmap parses the passed data, which makes it possible to access them directly. In the image below, you can see a change in a variable inside the query body: the title value has been replaced with the current time.

Sqlmap second-req/second-url

Purpose: send a request after the main request and payload.

Parameter:

Features:

• Second-req (but not second-url) may conflict with eval, which causes sqlmap to crash at the initialization stage (WAF check); and 
• Cannot be changed since tamper is called when payload (which is absent there) is processed; while eval is called in response to the main request or conflicts.

A request from second-req/second-url is made every time payload is executed. If payload isn’t executed, no second-req/second-url requests will be sent. The screenshot below shows that sqlmap doesn’t make a second-req request when test queries are sent (to check availability of the website).

Brief conclusions

Several mechanisms enable you to make additional requests: tamper, eval, and second request. Their brief comparison is provided in the table below.

Problems arising when multistep SQLi are exploited using sqlmap

The existing customizable mechanisms (i.e. tamper and eval) can only help when you make queries before the main payload and affect the query containing the main payload. In other words, they can be used at stages 1 (preparation) and 2 (injection).

Accordingly, sqlmap cannot be used to modify queries after the main query. The query from the second request cannot be changed; furthermore, it’s impossible to send more than one query, which might be required at stage 3 (confirmation) and stage 4 (result).

Overall, sqlmap can be used to exploit multistep injections, but such injections should be performed in only two or three (as maximum) stages.

In the simplest scenario (only the preparation stage is required), sqlmap can be effectively used to search for compound SQLi and exploit them.

Writing custom wrapper

In my opinion, the following testing scheme involving custom Python scripts is optimal for multistep SQLi:

1. There is a chain of requests (stage 1, stage 2, …); after each request, the status, time, and length of the response are checked, as well as the presence of out-of-bounds (OOB) requests to an external server;
2. These requests are performed in the function that takes payload. Then this payload is substituted into the requests (stage 1, stage 2, …); and 
3. The main function runs a function with a chain of five workers in parallel and passes to it the payload from the specified wordlist and the session cookie.

Code example

First, let’s import the required libraries, including concurrent.futures (to execute parallel requests).

The args_parser() function will parse the passed arguments:

Below is an example of the main function implementing multithreading for five workers. The script takes command line arguments and loads the path to the wordlist and session cookies to perform authenticated requests. After receiving all the data using the concurrent.futures.ThreadPoolExecutor abstraction, it creates a pool of workers that will execute the specified function. Threads are started using executor.submit, and the function that has to be executed and its parameters are passed to it.

Below is an example of a function passed to executor. It sends requests containing payload from the wordlist. In this example, the function consists of three parts: Create vars, STAGE 1, and STAGE 2. In Create vars, common values are set for all subsequent requests (e.g. the cookie value and the User-Agent header). The number of stages isn’t limited; they represent requests intended for different stages of the business logic. A new request corresponds to a new STAGE. In this particular example, two STAGES are presented for demonstration purposes.

It’s also important to track anomalies (i.e. ‘interesting’ results) that occur when payloads from the wordlist are transmitted. Below is an example of a function that handles such ‘interesting’ results: it measures the server response time (and triggers if it exceeds 10 seconds) and checks the response length relative to the ‘normal’ length.

In addition, it’s important to specify the server for OOB requests in transmitted payloads and check it for responses on a regular basis.

Conclusions

In almost all cases, the identification and exploitation of multistep SQLi requires some coding. If you use sqlmap, it’s required for tampering (sqlmap subsequently exploits the injection by its own). But currently, sqlmap cannot help in exploitation of multistep injections that require a confirmation request to be sent after the main request containing payload.

More sophisticated injections can be detected using custom scripts (that track status, length, and response time) and out-of-bound payloads. But in such cases, you have to exploit the detected injection manually.

How to protect against such attacks? The only effective way is to validate the data at all operational stages of the app, not just at the entry point.

Good luck in your searches for nontrivial injections!