我如何在旧的公共漏洞赏金计划中发现SQL注入漏洞

建议

如何发现别人没挖到的漏洞？

1.一定要测试集成API，BurpSuite扫描器可能无法覆盖这些API。

2.使用以下Google dork语法在现有目标中查找最近更新的页面，以发现新的功能或API进行SQL注入测试：

site: target.com after:10 september 2024

这些功能或 API 很可能还未被其他漏洞猎人探索过。

正文

我已经在这个漏洞奖励计划上进行了三年的漏洞挖掘。尽管这是一个非常老旧的项目，但我仍然能够在其中发现SQL注入漏洞。

目标：site.redacted.com

我登录该应用程序后，发现有一个供已登录用户使用的聊天框功能，用户可以通过该功能获得支持服务。由于这个聊天框是第三方提供的，我起初并没有进行过多测试，认为它应当属于范围之外。然而，我注意到该聊天框中出现了一个新的功能——“连接AI助手”。当启动这个AI助手时，它会在主聊天框中打开一个AI对话窗口。

那么，这部分功能是否属于范围之外？

为了找到答案，我使用BurpSuite拦截器拦截了“启动AI对话框”的请求，发现该操作会触发一个API请求，向聊天代理发送授权令牌，令牌来自site.redacted.com。

授权完成后，AI对话框启动。当我在对话框中输入文本并发送时，API请求会被发送到我们的目标主机。

请求的URL格式如下：

https://site.redacted.com/external-api/chat-agent/api/conversation/message

这是连接聊天代理的API，在POST请求体中包含了许多参数，因此我逐一对这些参数进行SQL注入测试。

我在所有参数中输入了单引号和双引号，试图发现是否存在基于错误的SQL注入漏洞，但没有成功。

通过Wappalyzer工具，我发现该站点的主域名正在使用MySQL数据库：

基于此信息，我推测该子域也使用MySQL，因此我在各个参数中尝试了MySQL的基于时间的SQL注入 Payload：

(select*(from(select(sleep(5)))a)

结果我发现userId参数存在漏洞，但事情似乎有些不对劲。我在sleep函数中输入了“5”，但应用程序的响应时间却为15秒。

为了进一步了解情况，我在负载中输入了“1”、“3”和“5”，并得到了以下结果：

1、sleep(1) -> 响应时间 = 3.9秒

2、sleep(3) -> 响应时间 = 9.9秒

3、sleep(5) -> 响应时间 = 15.9秒

结论：应用程序在每秒睡眠的基础上额外增加了大约3秒的延迟。可能是因为userId参数在SQL查询中被多处使用。但这种额外延迟并不会影响漏洞利用。

接下来，我使用SQLmap对数据库进行了转储：

在相同的请求中，另一个参数accountId也存在漏洞。我将以下SQL注入 Payload附加在accountId参数的现有值后，以实现延迟响应：

"accountId":"12345'+(select*(from(select(sleep(5)))a)+'"