一个链接，转漏点下去，转漏你以为是转漏去银行，结果掉进了钓鱼站。转漏这不是转漏什么高深的入侵，就是转漏url跳转漏洞在作祟。它可能是转漏所有web漏洞里最不起眼、却最容易被利用来捅娄子的转漏一个。

说白了，转漏这漏洞就是转漏开发者在做页面跳转时，没管好那个跳转地址参数。转漏比如`xxx.com/redirect?转漏url=`后面跟什么，程序就傻乎乎往哪跳。转漏攻击者把后面的转漏地址换成自己的恶意站点，就完事了。转漏就这么简单，不需要什么花哨的payload。

我见过不少真实案例。有个电商平台，用户登录后要跳回之前浏览的页面，开发图省事，直接用了`returnUrl`参数。结果呢？攻击者构造一个链接发给受害者，受害者一看，域名是官方的，放心点了，跳过去却是仿冒的支付页面。钱没到商家口袋，进了骗子的腰包。这类骗术在微博、贴吧里流传极广，中招的人不在少数。

更阴险的是配合其他漏洞用。比如某个站点的OAuth登录流程，回调地址没校验严，攻击者能窃取授权码。还有的利用跳转漏洞绕过WAF（防火墙）规则，把恶意流量伪装成正常跳转。你以为在访问A页面，实际上已经被悄悄带去了B页面，整个过程神不知鬼不觉。

有些开发朋友可能会说，我跳转时加了判断，只允许站内地址。可这判断往往不严谨。比如只检查了开头是不是`http`，那攻击者用`http://evil.com`照样过；或者只检查了域名是否包含目标站点名，那`target.com.evil.com`这种子域名欺骗也能蒙混过关。更别提那些用`//`开头的协议相对地址，浏览器会自动补全协议，直接跳转外站。

修复的思路其实不复杂。最稳妥的办法是白名单机制，把允许跳转的域名写死，不在名单里的一律拒绝。如果业务确实需要灵活跳转，那就老老实实对参数做签名，服务端验证签名有效才能跳。别嫌麻烦，安全这东西，偷懒一时爽，出事火葬场。

我还想吐槽一点。很多安全报告里，url跳转漏洞往往被标为“低危”，很多公司不重视。可现实是，它经常是社工攻击的完美第一步——用户对官方域名的信任感被直接消耗殆尽。一次成功的跳转钓鱼，可能抵得上十次暴力破解。你说它低危，但利用起来，杀伤力一点不比SQL注入小。

所以，下次看到代码里那个裸奔的`redirect`参数，别急着忽略。多问一句：这个跳转真的安全吗？