用豆包辅助挖SSRF漏洞：AI安全测试全流程实战解析

挖漏洞拿赏金早已不是什么行业秘密——在正规SRC（Security Response Center）平台提交漏洞变现，是不少安全从业者和爱好者的日常。而随着大模型能力的提升，越来越多人开始尝试借助AI工具提升挖洞效率。这篇文章基于一位B站UP主的实战演示，拆解如何用豆包辅助完成一次完整的SSRF漏洞挖掘，从思路到验证一步步走通。

重要前提：所有测试必须在已授权的SRC平台或自建靶场内进行。私自扫描、测试未授权网站属于违法行为，这一点无论如何强调都不过分。

AI辅助挖洞的完整流程

整个AI辅助挖洞被拆解为六个步骤：部署AI挖洞所需环境、确认授权测试范围、收集目标信息、漏洞扫描、人工核验漏洞真实性、整理漏洞报告。

这套流程的价值在于，它并不要求新手上来就精通一堆复杂代码——有一台电脑就能入门。AI在这里承担的是"经验放大器"的角色：把人类专家的测试思路编码成提示词，让模型按既定路径自动分析，再由人工去验证真实性。

需要清醒认识到的是，AI并不能替代对漏洞原理的理解。它更像是一个熟悉套路的助手，而判断最终结果是否成立、是否构成真实风险，仍然依赖测试者的核验。

表面上看起来普通的URL预览功能

测试对象：一个"普通"的URL预览功能

本次演示的目标是一个常见的URL预览功能。在输入框里填入一个网址（比如百度），点击预览后，页面会把对应网页内容抓取并显示出来。

表面看这就是个普通的网页预览功能，但安全测试的核心思维恰恰在于"多往深处想一步"。关键问题是：如果输入的不是百度这类公网地址，而是只有服务器自己才能访问的内部地址——比如服务器内网的管理后台、内部服务端口——这个功能是否也会乖乖地替我们去访问并返回内容？

如果答案是肯定的，那么这里就存在SSRF（Server-Side Request Forgery，服务端请求伪造）漏洞。其本质是：利用网站的某个功能，让服务器替攻击者去访问那些本不该被访问的地址。

这类场景在实战中极为普遍。凡是涉及网页预览、图片加载、地址检测的功能，都值得多留意——留意我们提供的地址究竟能让服务器访问到什么内容。

SSRF（Server-Side Request Forgery，服务端请求伪造）之所以危险，根源在于服务器通常处于内网中，能访问到外部用户完全无法直接触达的资源：内网管理系统（如 Jenkins、Kubernetes API、Redis）、云服务商的元数据接口（如 AWS 的 169.254.169.254，可获取实例凭证）、以及本机文件系统。攻击者通过控制服务器发出的请求地址，相当于借服务器的"身份"做了一次内网漫游。SSRF 漏洞在 OWASP Top 10 2021 版中被单独列为一类（A10），正是因为现代云原生架构中微服务、容器化部署普遍，内网服务间信任关系复杂，一旦出现 SSRF，横向移动的攻击面极大。

提示词设计：把专家经验拆解给AI

要让豆包真正发挥作用，提示词的质量是关键。演示中强调，写这份提示词绝不是简单一句"帮我测一下SSRF"就结束，而是要围绕整个请求链路去设计。

围绕请求链路设计的提示词

具体来说，提示词包含了几层信息：

完整的目标信息

先把目标信息整理清楚交给模型，包括测试地址、登录状态、具体的预览接口以及URL参数的位置。目的是让豆包先搞清楚"入口在哪里、从哪里下手"。

分步测试路径

把人类做SSRF测试的实际思路提前规划成路径：第一步先确认功能是否真的存在服务端请求；确认之后再往深处测，比如探测内网服务和端口、尝试访问内网敏感文件。这些都是SSRF最常见的风险方向。

协议层面的检查

一个容易被忽视的细节是网址前面的协议。平时访问网站用的是HTTP/HTTPS，但如果网站没做好严密限制，就可以尝试一些特殊协议，比如 Gopher 协议，看看功能除了抓取正常网页外，还能不能读取或访问其他类型的资源。如果特殊协议也能被处理，SSRF的利用范围会大幅扩大。

从入口确认到外部请求验证的完整思路

本质上，这份提示词就是把SSRF测试经验完整拆解：从入口确认，到外部请求验证，再到内部资源探测、协议检查，每个关键测试点都提前设计好。对还不会写这类提示词的新手来说，这套结构可以直接套用到类似场景。

Gopher 协议是一种诞生于 1991 年的早期互联网文档传输协议，本身已基本废弃，但在 SSRF 利用中却因其能"打包"任意 TCP 数据流而被重新激活。通过构造形如 gopher://127.0.0.1:6379/_*1\r\n 的 URL，攻击者可以向目标服务器的任意端口发送原始字节序列，从而直接与 Redis、Memcached、MySQL 等服务"对话"，执行命令或写入 WebShell。除 Gopher 外，常被检测的危险协议还包括：file://（读取本地文件）、dict://（探测端口开放状态）、ftp://（有时可绕过过滤）。因此，防御 SSRF 仅靠过滤 HTTP 请求远远不够，必须在服务端对协议类型做严格白名单限制。

结果：不止SSRF，还挖出任意文件读取

豆包按照这套思路执行后，输出的漏洞清单超出了预期——它不仅确认了URL预览功能存在SSRF漏洞，还进一步验证出了任意文件读取问题。

豆包的测试过程是这样的：先用账号密码登录测试网站，获得正常测试入口；随后把请求地址换成 file:///etc/passwd，用于读取服务器本地的账号文件。读取成功后，它没有停在这里，而是继续尝试读取其他系统文件，发现都能读出来。

从预览功能升级为任意文件读取

问题的严重性到这一步就很明显了：本来只是预览网页的功能，结果连服务器上的本地文件都能被读出来，这已经构成任意文件读取。

/etc/passwd 是 Linux/Unix 系统上存储用户账号信息的标准文件，记录了系统中每个用户的用户名、UID、GID、主目录和默认 Shell 等信息。在现代系统中，密码哈希已单独存放于 /etc/shadow（权限更严格），所以读取 passwd 本身不会直接泄露密码，但它能暴露系统用户列表，为进一步攻击（如猜解 SSH 账户、提权路径分析）提供重要情报。任意文件读取漏洞的真正危险在于攻击者可继续读取 /proc/self/environ（环境变量，可能含密钥）、应用配置文件（数据库连接串）乃至私钥文件，使漏洞危害从信息泄露快速升级为完全失陷。

人工验证：AI给思路，人来确认

搞清楚过程后，关键的最后一步是实际动手验证。这也是整个流程中不可省略的环节——即便部分技术细节暂时没看懂，也可以跟着豆包给出的思路去操作核验。

按照同样的方式，在预览功能里输入相同的地址、点击查看，服务器上的文件内容确实被返回来了。至此可以基本确认，这个URL预览功能确实存在SSRF漏洞，并可升级为文件读取。

按演示的说法，这类漏洞如果能在真实SRC或漏洞赏金平台成功挖出并提交、通过审核，拿到500元甚至更高的赏金都属常态。

核心判断逻辑：一句话抓住本质

抛开具体工具和技术细节，真正值得记住的是判断思路：只要一个网站能按照我们的要求去访问某个地址，就值得进一步测试——看它是否连那些本不该被访问的地址也能访问到。

这个思路可以泛化到大量功能场景。AI工具在这里的意义，是把这套经验流程化、自动化，降低了新手的入门门槛。但它同时也放大了一个风险信号：越是低门槛的攻击手段，越提醒开发者必须对SSRF这类问题做严格防护——对用户可控的URL做协议白名单、禁止访问内网地址、过滤 file:// 等危险协议。

最后再次重申：以上所有内容均在授权环境中完成，技术学习的边界永远是法律与授权范围。AI让挖洞更高效，但也让"是否授权"这条红线变得比以往任何时候都更需要被敬畏。