|
检测到目标URL存在链接注入漏洞。检测接注这不是到目洞什么新鲜事，但每次在实战中撞见，存链我还是入漏会心头一紧。三周前，检测接注某省一家制造业客户的到目洞官网后台，就被这个老掉牙的存链漏洞捅了个对穿。攻击者只往查询参数里塞了一个经过编码的入漏javascript:协议链接，配合一个诱导点击的检测接注短链，就绕过了前端的到目洞全部过滤。运维日志显示，存链恶意请求来自凌晨两点十七分，入漏持续了四十三秒。检测接注就这四十三秒，到目洞后台管理员的存链会话令牌被偷走了。 链接注入的本质，是程序把用户可控的输入，未经严格校验就拼进了输出页面里的链接地址。常见于搜索结果页、文章引用处、用户资料编辑框，甚至某些支付回调。攻击者不需要多高深的技术，一个<a href="javascript:alert(1)">就能试探出深浅。但真正可怕的不是弹窗，而是后续的钓鱼跳转、会话劫持、甚至配合CSRF发起转账。 我见过最典型的误判，是某团队把链接注入和URL重定向漏洞混为一谈。它们确实长得像——都涉及URL。但重定向漏洞是服务端把用户输入直接作为跳转目标，链接注入则是把恶意链接写进页面内容里，等受害者自己去点。前者靠302响应头，后者藏在HTML源码中。诊断时看响应体里的标签href属性，比看Location头靠谱得多。 修复方案倒是直白。后端必须做白名单校验，只允许http和https协议，其他一律拒绝。同时要对输出做HTML实体编码，把双引号、尖括号这些特殊字符转义掉。别指望前端JS过滤，那玩意关掉就能绕过。还有个细节容易被忽略：链接注入不一定只走href，src、action、甚至form的onsubmit事件都可能成为载体。所以别只盯着用户输入的地方，所有动态生成URL的拼接点都得过一遍。 那次排查最后，我在客户的CMS里翻出一个老旧的第三方编辑器插件，它把用户输入的链接直接塞进window.open()。补丁打了，漏洞堵了，但第二天我又在另一个上传接口里发现了类似的拼接逻辑。说句实话，这类漏洞反复出现，根子不在技术，在于开发流程里缺少一个强制性的安全评审环节。代码写得再快，不如先花十分钟想想：这个输入值，最终会出现在哪个HTML属性的哪个位置？ 你手头要是有类似的URL拼接点，别急着测payload。先打开浏览器开发者工具，在Network面板里看响应体源码，搜索所有带href或src的地方，逐个核对来源。如果发现某个属性的值能直接对应到请求参数，那就是嫌疑点。用Burp Suite改包，把参数值换成https://evil.com，看响应里是否原样回显。回显了，基本就坐实了。剩下的，就是按上面的方法修，别拖。 | 
喜欢
讨厌