url重定向漏洞

上周帮朋友看一个电商站，漏洞点进“登录后跳转”的漏洞链接，发现URL里挂着个?漏洞redirect=https://evil.com。改掉域名，漏洞页面直接蹦到钓鱼站。漏洞用户刚输完账号密码，漏洞下一秒就被送走。漏洞这不是漏洞个例，是漏洞url重定向漏洞最典型的嘴脸。

说白了，漏洞这漏洞就是漏洞服务端太信任用户传进来的跳转地址。你给它什么，漏洞它就带你去哪。漏洞攻击者把恶意链接伪装成正常站内跳转，漏洞比如https://shop.com/login?漏洞next=//attacker.com。用户看到域名是shop.com，放心点击，结果被弹到外部。浏览器地址栏一闪而过，普通人根本来不及反应。

我见过最离谱的案例，某银行APP的H5页面，重定向参数直接拼在returnUrl里。攻击者构造returnUrl=https://bank.com.evil.cn，用户登录后跳过去，页面长得和银行一模一样。连证书都是真的——因为攻击者用了个子域名。这种叫“开放重定向”，OWASP把它归到“未验证的重定向和转发”里，常年霸榜。

为什么难防？因为开发者的直觉是“我只要校验域名白名单就行”。但白名单经常写成endswith(".bank.com")，攻击者注册evil-bank.com就绕过了。还有人用startswith("https://bank.com")，那https://bank.com.evil.com呢？照样中招。

更隐蔽的是用@符号。URL里https://bank.com@evil.com，浏览器实际访问evil.com，但用户扫一眼只看到bank.com。这种老把戏现在依然管用，尤其在一些老系统里。

我试过在一个开源CMS里找这类漏洞。搜索redirect、return、next、url=这些参数，十分钟内找到三个。其中一个在密码重置流程里：用户点邮件里的链接，token验证通过后，直接header("Location: ".$_GET['redirect'])。攻击者可以骗用户点一个“重置密码”链接，实际跳去钓鱼页，用户以为要重新登录，就把新密码输进去了。

修复方案其实不复杂。别用用户传的完整URL，只允许相对路径，比如/dashboard。如果必须跳外部，维护一个映射表，用ID代替URL。比如?target=1对应https://partner.com，用户改不了。再狠一点，跳转前弹个确认页，显示“你将离开本站，前往xxx”，让用户自己判断。

但现实是，很多业务为了“用户体验”，把重定向做得太灵活。登录后回原页、支付后回商户、分享后回活动页，每个场景都留个口子。安全团队提了，产品经理说“影响转化率”。最后漏洞就挂在那，等哪天被薅了才修。

我自己的习惯：看到任何带url=、redirect=、next=、return=的链接，先手动改个//example.com试试。如果跳过去了，这站基本可以拉黑。普通用户没这意识，所以只能靠开发者把口子扎紧。别让一个参数，把用户送到别人手里。

很赞哦!（958）