去年冬天，重定我帮一个做跨境电商的向漏朋友查后台日志，发现有人把站内搜索页的重定跳转参数改成了外部域名。用户点进去，向漏浏览器先经过他们服务器，重定再被扔到钓鱼站。向漏整件事最离谱的重定地方在于：那个跳转参数压根没做白名单校验，连正则都只写了“http”开头就算过。向漏

这就是重定重定向漏洞。服务器收到一个带跳转地址的向漏请求，没验证目标是重定否可信，直接让浏览器跳过去。向漏攻击者要做的重定，只是向漏把那个参数换成自己的站点。

很多人觉得这玩意儿危害不大——不就是重定跳个页吗？又没拿到数据。但真实攻击链里，重定向往往是第一步。用户看到的是你域名下的链接，信任感还在，跳转之后页面长得一模一样，输入账号密码顺理成章。OAuth 流程里更致命：授权服务器如果允许任意 redirect_uri，攻击者就能把授权码截到自己服务器上，直接接管账号。2019 年某知名代码托管平台就出过这类问题，安全研究员用一个精心构造的 redirect_uri 绕过了校验，拿到了私有仓库的访问权限。

重定向漏洞的触发点比想象中多。登录成功后的 returnUrl、支付完成后的 callback、短链接服务的目标地址、甚至 404 页面里的“返回首页”参数，都可能成为入口。我见过最隐蔽的一个案例，是某网站的语言切换功能：?lang=zh&next=https://evil.com，前端只检查了 lang 字段，next 直接丢给 window.location.href。

防御思路不复杂，但细节容易翻车。最稳妥的做法是维护一个允许跳转的域名白名单，用精确匹配而不是包含匹配。有人喜欢用 startsWith 判断，攻击者注册一个 https://trusted.com.evil.com 就绕过去了。还有人只校验协议，觉得 https:// 开头就安全，但 https://evil.com 也是 https 开头。

如果业务上确实需要跳转到用户指定的外部地址，中间加一个确认页。告诉用户“您即将离开本站，前往 xxx.com”，让用户自己点确认。这个页面本身不承担安全校验，但能打断自动化攻击链，也给用户一个判断机会。OAuth 场景下，redirect_uri 必须提前注册，授权服务器做精确匹配，不支持通配符。

我自己的习惯是，任何接收 URL 参数的接口，先问三个问题：这个参数会不会被浏览器执行跳转？跳转目标是否可控？如果可控，有没有白名单？三个问题里只要有一个答案是“是”或“没有”，就得停下来改代码。听起来很笨，但比出事之后写事故报告轻松多了。

重定向漏洞不像 SQL 注入那样能直接拖库，也不像 XSS 那样能弹窗。它更像一把钥匙，单独看没什么用，但配合其他漏洞就能打开很多门。很多开发者在代码审查时看到 response.sendRedirect(request.getParameter("url")) 这种写法，觉得“只是跳转而已”，随手就放过了。攻击者最喜欢的就是这种随手放过。

上周我又看了一眼那个跨境电商的后台，跳转参数已经换成了枚举值，?target=order 映射到固定路径。改法很土，但有效。安全这件事，有时候土办法比花哨的方案管用。