手无寸铁，智取三“洞”：一个渗透测试员的手动狩猎纪实

没有炫酷的工具，没有自动化的脚本，仅用最纯粹的思维能力与逻辑链条，在三个目标上成功捕获漏洞。

作者：Mado (Mohamed)，一名专注的Web应用渗透测试员与漏洞赏金猎人

阅读提示： 本文记录了三次手动漏洞挖掘的实战过程，重点关注信息泄露与开放重定向两种类型。泡上一杯咖啡，让我们开始这场思维的冒险。如果你喜欢这篇文章，别忘了“点赞”鼓励哦！

第一“洞”：藏匿于聊天室中的全员通讯录（信息泄露）

目标概览 #1

我的第一个目标是一个在线协作文档应用。用户可以在其中创建文档、记录内容，并邀请他人以不同角色（如查看者、编辑者、管理者）进行协作。权限模型看起来设计合理。

我的攻击思路与技巧：

我创建了一个文档，并将其设置为“公开链接”可访问。这意味着任何拥有此链接的人，即使不是团队的一员，也能以“查看者”身份进入文档页面。

当我以外部攻击者的身份访问该公开链接时，页面看起来一切正常——我只能看到文档内容，无法浏览团队列表或其他敏感信息，这符合预期。

然而，我注意到了页面上的“团队聊天”功能区。我输入了一条测试消息并发送，与此同时，我打开了Burp Suite等拦截工具，捕获了发送消息的HTTP请求。

关键一步：逻辑推理与试探

通常情况下，发送消息会使用 POST 方法。我捕获到的请求也确实是 POST /api/chat/messages。但一个想法闪过：如果我将这个创建消息的 POST 请求，改为获取消息的 GET 请求，服务器会作何反应？

在某些设计不当的API中，后端可能没有为同一个路由（Endpoint）严格区分不同HTTP方法的权限校验逻辑。POST 需要验证用户是否有“写”权限，而 GET 可能只验证了用户是否“能访问这个页面”，但具体的数据权限校验可能被遗漏。

于是，我手动将拦截到的 POST 请求方法修改为 GET，然后将其转发。

结果：权限围墙轰然倒塌

服务器没有返回错误，而是返回了一个JSON响应。里面赫然包含了团队内所有成员的详细信息：姓名、电子邮箱等。而我，仅仅是一个通过公开链接进来的、未经认证的“幽灵”用户。

漏洞根源： 服务器端在处理 /api/chat/messages 的 GET 请求时，错误地将其与“查看团队信息”的权限进行了绑定，或者完全漏掉了对数据范围的过滤。它可能只检查了“用户是否能访问这个聊天频道”（对于公开文档，答案是肯定的），却没有检查“用户是否有权查看这个频道里的所有历史消息和参与者信息”。

第二“洞”：潜伏在配置文件里的“跳板”（开放重定向）

目标概览 #2

第二个目标是一个日常任务管理应用。在对其资产进行信息搜集（Reconnaissance）时，我发现了其配置的一个MCP服务器端点。

在浏览其页面源码或网络请求时，我看到了一个类似如下的配置项：

APP_ICON=https://blablabla.com/logo.png

这看起来是用来设置应用图标URL的。开放重定向 漏洞的经典场景：如果应用在重定向时，未严格校验目标URL是否属于自身域名，攻击者就能构造恶意链接，将用户导向钓鱼网站。

我开始了我的“绕WAF（如果存在）与逻辑校验”之旅：

1. 直接替换：https://evil.com → 失败。服务器可能进行了简单的域名白名单校验。
2. 尝试经典绕过payload：
   • https://[email protected] （利用@语法） → 失败。
   • https://blablabla.com?evil.com （附加查询参数） → 失败。
   • https://blablabla.com/evil.com （作为路径） → 失败。
3. 思维转换：白名单校验很可能是在检查URL的“开头”部分。如果我让URL依然以可信域名 开头，但通过一种浏览器会以不同方式解析的格式呢？
4. 决胜payload：//evil.com
   • 这是一个协议相对URL。当它在 href 或重定向头中被使用时，浏览器会继承当前页面的协议（http: 或 https:），最终导向 https://evil.com。
   • 妙处在于，对于许多简单的字符串匹配或正则校验来说，//evil.com 并不会触发对“blablabla.com”的匹配失败，因为它看上去像是一个路径。但对于浏览器和网络栈，这就是一个完整的外部域名。

漏洞验证：

我将配置中的 APP_ICON 值改为 //evil.com。保存后，在应用中点击相关功能（如MCP代理连接点），观察浏览器状态栏或使用调试工具。成功！用户在点击后，被重定向到了 evil.com。

注意看，光标悬停时，浏览器左下角显示的目标链接已是 evil.com。

漏洞根源： 后端在重定向或加载外部资源时，对用户可控的URL参数采用了过于简单或存在缺陷的校验逻辑，未能识别出 // 开头的这种特殊格式，导致可以绕过白名单限制。

第三“洞”：伪装成图片的“传送门”（SVG导致的开放重定向）

目标概览 #3

第三个目标与第二个类似，也是协作类应用。这次我关注的是其团队聊天功能中的图片上传。

我尝试了常见的XSS（跨站脚本）payload，但应用似乎对HTML和脚本标签过滤得不错，没有成功。

思维转换：XSS不行，那开放重定向呢？有没有一种“图片”，既能通过图片格式校验，又能执行跳转逻辑？

答案就是：SVG（可缩放矢量图形）。SVG本质上是XML文本，可以被浏览器渲染为图像，但同时它可以内嵌JavaScript。

构造攻击Payload：

我创建了一个包含恶意脚本的SVG文件，将其伪装成一张简单的红色圆形图片：

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
    <script>
        // 当SVG被浏览器加载时，立即将页面重定向到恶意网站
        window.location.replace("https://evil.com");
    </script>
    <circle cx="50" cy="50" r="40" fill="red" />
    <text x="50" y="55" text-anchor="middle" fill="white">诱惑性文字，如“查看详情”</text>
</svg>

攻击过程：

1. 在团队聊天中，以普通用户身份上传这个SVG文件作为“图片”。
2. 服务器端可能只检查了文件扩展名（.svg）或简单的MIME类型，没有对文件内容进行深入的恶意代码扫描，便将其存储并标记为可信任的用户生成图片。
3. 当其他团队成员（受害者）打开聊天界面时，他们的浏览器会加载并渲染这张“图片”。
4. SVG内的 <script> 标签被执行，页面在用户毫无知觉的情况下被重定向至 evil.com。

漏洞根源： 应用的文件上传功能存在 “内容与类型不匹配” 的安全缺陷。它允许上传SVG这种活跃内容格式，却没有在服务端或客户端对SVG文件内容进行 sanitization（净化处理），尤其没有剥离或禁用其中的 <script> 标签。同时，在展示用户上传的SVG时，可能没有使用 <img> 标签的 src 属性（这会阻止脚本执行），而是直接内嵌了SVG代码或使用了不安全的渲染方式。

狩猎成果与心得

通过这三场“纯手动”的狩猎，我成功地向相关安全团队报告了这些中高风险漏洞，并获得了认可与奖励。

最重要的一点心得，我想分享给所有安全研究员和开发者：

一个攻击向量或思路，在一个地方不成功，绝不意味着它本身是无效的。 现代应用架构复杂，不同功能模块可能由不同团队开发，安全控制策略不尽相同。在同一款应用中，你可能会发现：

• 主站登录有严格的二次验证，但移动API接口却遗漏了。
• 用户资料上传过滤了所有脚本，但文章评论的富文本编辑器却存在XSS。
• （正如我的案例）文档权限检查严密，但聊天API的权限校验却存在逻辑缺陷。

这种“同源不同策”的现象，正是手动、深度逻辑测试最能发挥价值的地方。 自动化扫描器擅长发现已知的、模式化的漏洞（如已经公开的SQLi payload），但对于需要理解业务上下文、串联多个功能点、利用逻辑瑕疵的漏洞，人类的推理能力和创造力仍然不可替代。

漏洞挖掘，很多时候不是工具的比拼，而是思维的较量。你需要像攻击者一样思考，提出“如果…会怎样？”的问题，并耐心地、有条理地去验证你的每一个假设。

保持好奇，保持怀疑，逻辑将为你指明通往漏洞的道路。

原文：https://medium.com/@0xMado-1Tap/how-i-got-3-bugs-no-automation-just-logic-65f372c664cd