使用 sqlmap 的 Level 和 Risk 参数调整扫描侵略性

引言

sqlmap 是一个强大的开源渗透测试工具，可以自动化检测和利用 SQL 注入漏洞的过程。在进行扫描时，你可以控制的两个最重要的参数是 --level 和 --risk。这些参数决定了扫描的彻底性和攻击性。

• Level: 控制执行的测试数量。它范围从 1 到 5，级别越高，对更多的注入点（如 HTTP 头部）执行的测试越广泛。
• Risk: 控制所用 payload 的风险级别。它范围从 1 到 3，风险级别越高，使用的 payload 可能越具破坏性（如可能导致数据库变慢的时间型查询）。

在本实验中，你将学习如何使用这两个参数来微调你的 sqlmap 扫描。你将从默认扫描开始，逐步提高 level 和 risk，以观察它们如何影响扫描的范围、持续时间和使用的 payload 类型。

理解默认 Level (1) 和 Risk (1)

在此步骤中，你将执行一次基础的 sqlmap 扫描，而不指定 level 或 risk。默认情况下，sqlmap 使用 --level=1 和 --risk=1。这是最不全面且最安全（风险最低）的扫描。

Level 1 仅测试 GET 和 POST 参数。Risk 1 使用对 Web 应用程序通常无害的 payload，例如基础的布尔型和错误型注入测试。

让我们针对为你设置的易受攻击的应用程序运行默认扫描。--batch 选项会自动以默认选择回答所有问题，使扫描变为非交互式。

在你的终端中执行以下命令：

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

你将看到 sqlmap 开始其测试过程。请注意结尾的摘要，它显示了发出的请求数量和发现的漏洞。

...
[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'
...

这次初始扫描相对较快，并确认了 id 参数中的漏洞。

使用 --level=3 增加扫描深度

在此步骤中，你将通过将 level 设置为 3 来增加扫描的深度。更高的 level 会告诉 sqlmap 执行更多测试并检查其他位置的漏洞。

• --level=2 会增加对 HTTP Cookie 头部的测试。
• --level=3 会增加对 HTTP User-Agent 和 Referer 头部的测试。

通过提高 level，你要求 sqlmap 进行更彻底的检查。这自然会增加请求数量和扫描持续时间。

现在，再次运行扫描，但这次添加 --level=3 选项：

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

观察输出。你将注意到 sqlmap 现在明确提到了测试 Cookie 和 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'
...

尽管我们简单的应用程序不通过这些头部存在漏洞，但实际应用中可能会。你应该会注意到 HTTP 请求的总数（YYY）比上一步（XXX）要高。

使用 --risk=2 增加扫描侵略性

在此步骤中，你将探索 --risk 参数。此参数控制所用 payload 的“危险性”。

• --risk=1 (默认): 使用大部分无害的 payload。
• --risk=2: 添加了重型查询时间盲注测试。这些测试可能给数据库服务器带来显著的负载。
• --risk=3: 添加了基于 OR 的 SQL 注入测试以及其他可能具有破坏性的 payload，这些 payload 可能会修改数据。

更高的风险可以发现更安全的测试可能遗漏的漏洞，但它也增加了破坏目标系统的可能性。应谨慎使用。

让我们运行一次具有更高风险的扫描。我们将回到默认级别 (1) 以隔离风险参数的影响。

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

在本次扫描中，你将看到 sqlmap 采用更具侵略性的时间盲注技术。这些 payload 通过让数据库执行耗时的操作（如 benchmark 或 sleep 函数），然后测量服务器的响应时间来推断信息。

...
[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
...

即使在相同 level 下，使用 --risk=2 的扫描也比默认扫描更耗费资源，因为 payload 本身更复杂。

执行结合了 --level=5 和 --risk=3 的扫描

在此步骤中，你将结合最高 level 和 risk 设置，以实现最全面和最具侵略性的扫描。

• --level=5: 最高级别。它会测试所有可能的注入点，包括 HTTP Host 头部。
• --risk=3: 最高风险。它使用可能修改数据库条目的 payload。这很危险，只能在你有明确的破坏性测试权限的系统上使用。

这种组合会导致扫描非常耗时且强度很高。这是一种“无所不包”的方法，将所有已知的测试都应用于目标。

执行以下命令。请注意，此扫描将比之前的扫描花费更长的时间。

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

你将看到 sqlmap 使用其最强大的 payload 对所有可想象的注入点运行大量测试。

...
[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
...

此扫描展示了 sqlmap 的最大能力，但也突显了理解权衡的重要性。在标准渗透测试中，此类扫描通常不切实际且风险过高。

观察 Payload 和扫描时长的增加

在最后这个步骤中，你将回顾之前扫描的结果。没有新的命令需要运行。目标是通过比较扫描摘要来理解调整 level 和 risk 所带来的影响。

如果你回顾每个步骤的终端输出，你会注意到一个清晰的模式：

1. 默认扫描 (--level=1, --risk=1): 基线。它速度快，发送的请求最少。
2. 增加 Level (--level=3): 请求数量增加，因为 sqlmap 测试了更多的注入点（Cookie, User-Agent）。时长也相应增加。
3. 增加 Risk (--risk=2): 扫描时长增加，不一定是由于更多的请求，而是因为时间盲注 payload 本身就比较慢。
4. 最大侵略性 (--level=5, --risk=3): 此扫描发送了数量庞大的请求，并且完成时间显著最长。

以下是预期行为的摘要：

关键的收获是存在直接的权衡。增加 level 和 risk 可以提供更彻底的测试，并增加发现隐蔽漏洞的机会，但代价是扫描时间显著增加，以及破坏目标系统的风险更高。

总结

在此实验中，你已成功探索了如何使用 --level 和 --risk 参数来调整 sqlmap 扫描的侵略性。

你了解到：

• --level 控制扫描的范围，决定了 HTTP 请求的哪些部分会被测试漏洞。更高的级别更全面。
• --risk 控制扫描的侵入性，决定了使用的 SQL payload 类型。更高的风险更有可能找到漏洞，但可能对目标数据库造成危险。
• 默认设置（level=1, risk=1）旨在快速且安全。
• 增加这些值会导致更长的扫描时间，并需要更加谨慎。

作为最佳实践，始终从较低的 level 和 risk 设置开始。只有在初始扫描不成功，并且你拥有执行更具侵略性测试的适当授权时，才应升级它们。恭喜你完成了这个实验！