跳转漏洞

去年十月，跳转漏洞一个做独立站的跳转漏洞朋友给我发了条链接。他说你点开看看，跳转漏洞别登录，跳转漏洞就点。跳转漏洞我点了。跳转漏洞页面跳转到一个仿得极像的跳转漏洞某电商后台登录页，域名只差一个字母。跳转漏洞他问我：看出问题了吗？跳转漏洞我说域名不对。他说对，跳转漏洞但真正的跳转漏洞漏洞不在这儿——你刚才从微信里点开的那一瞬间，我的跳转漏洞服务器已经拿到了你的微信内置浏览器UA、粗略地理位置，跳转漏洞还有referer里带的跳转漏洞那串参数。

这就是跳转漏洞跳转漏洞的日常形态。它不靠攻破服务器，靠的是你点的那一下。

很多人以为“跳转”只是网页之间换个地址。实际上一串URL里能塞的东西远比想象中多。比如最常见的开放重定向：https://trusted-site.com/redirect?url=https://evil.com。用户看到的是大站域名，点下去却落到别处。早年微博、QQ空间都出过这类问题，攻击者把钓鱼链接包装成“官方跳转”，点击率翻好几倍。后来平台加了白名单，但绕过手法一直没断过——用//evil.com、用https:/evil.com少一个斜杠、用@符号让浏览器把前面当用户名。这些不是理论，是我在漏洞平台上亲眼翻到过的提交记录。

更隐蔽的是客户端跳转。有个案例我印象很深：某银行App的H5活动页，用location.href接收参数做跳转。参数没过滤，攻击者构造了一个javascript:伪协议。用户点“立即参与”，页面没跳走，但一段脚本在WebView里执行了。那段脚本能读本地存储里的登录token。整个过程页面纹丝不动，用户只觉得“怎么没反应”，然后关掉。token已经发出去了。

我后来自己复现过这个场景。用安卓WebView写了个壳，加载那个有问题的页面，构造参数，点按钮。控制台打印出token的时候，后背有点凉。因为整个攻击链里，用户唯一做的动作就是“点了一下”。没有下载，没有输入密码，没有授权。

跳转漏洞的麻烦在于它太“正常”了。正常到开发觉得“不就是个跳转吗”，正常到测试只测了正向流程，正常到用户根本不会怀疑一个从官方App里点开的链接。可攻击面恰恰藏在这种“正常”里。参数校验、协议白名单、域名后缀匹配——少做一步，就是一个口子。

还有个变种是服务端跳转。比如response.sendRedirect(request.getParameter("next"))，如果next没校验，攻击者可以构造next=//evil.com。用户登录成功后“自动跳转”，实际上被送到了钓鱼站。这种漏洞在OA系统、统一认证平台里特别多。因为业务逻辑就是“登录后回到原来页面”，开发很容易直接拿参数拼跳转地址。

我见过一个最离谱的：某政务平台，next参数直接拼在Location头里。攻击者用%0d%0a注入换行，硬生生在响应头里插了个Set-Cookie。这叫HTTP响应拆分，配合跳转漏洞用，能直接给用户种下恶意Cookie。那会儿我盯着Burp里的响应包看了半天，心想这也能行。

说回开头那个朋友。他后来在公众号发了篇复盘，阅读量一般。评论区有人说“这不算漏洞吧，用户自己不看域名”。他没回。我知道他怎么想——用户看不看域名，和系统该不该做校验，是两码事。把安全责任推给用户，本身就是最大的漏洞。

跳转漏洞不会消失。只要还有“登录后跳回”“分享后跳转”“支付后回调”，它就一直在。区别只在于，做系统的人有没有把那个参数当回事。我现在的习惯是，看到任何带url=、next=、redirect=的链接，先改个域名试试。十次里能中一次，那次就够写一份报告了。