0x1 前言
这几天跟着我那几个师傅们在学习URL重定向漏洞，学习了比较多的对于这个漏洞的骚技巧以及在挖掘edusrc漏洞和企业src相关的URL重定向漏洞时的一些技巧和不错的思路。
最近在跟我那几个师傅们研究学习URL重定向漏洞，然后在一些厂商项目中开始接触到一些url任意重定向，虽然是低危，奖金较低，但是一个厂商所有点的url跳转加起来奖金也比较可观，所以将自己挖掘过程中一点点心得分享一下。
经典钓鱼网站
来看个最典型的
$url=$_GET['URL'];header("Location: $url");
先走个流程说些废话，url重定向漏洞也称url任意跳转漏洞，网站信任了用户的输入导致恶意攻击，url重定向主要用来钓鱼，比如url跳转中最常见的跳转在登陆口，支付口，也就是一旦登陆将会跳转任意自己构造的网站，如果设置成自己的url则会造成钓鱼。
URL没有任何限制，所以恶意用户可以提交
http://www.aaa.com/login.php?...://www.bbb.com(钓鱼网站)来生成自己的恶意链接，安全意识较低的用户很可能会以为该链接展现的内容是www.aaa.com从而可能产生欺诈行为
成功跳转到百度
0x02 URL重定向漏洞描述
也称URL跳转、URL重定向漏洞，由于目标网站未对程序跳转的URL地址及参数做合法性判断，导致应用程序直接跳转到参数中指定的的URL地址。攻击者可通过将跳转地址修改为指向恶意站点，即可发起网络钓鱼、诈骗甚至窃取用户凭证等
常见应用场景
主要是业务逻辑中需要进行跳转的地方。比如登录处、注册处、访问用户信息、订单信息、加入购物车、分享、收藏等处。
下面我要给师傅们分享的URL重定向漏洞就是在给别人分享一个二维码，通过bp抓包然后篡改里面的URL跳转地址，然后导致扫描的二维码直接跳转到恶意地址，从而导致一个URL重定向src成功执行
url跳转常见出现的地方
1. 登陆跳转我认为是最常见的跳转类型，认证完后会跳转，所以在登陆的时候建议多观察url参数
2. 用户分享、收藏内容过后，会跳转
3. 跨站点认证、授权后，会跳转
4. 站内点击其它网址链接时，会跳转
5. 在一些用户交互页面也会出现跳转，如请填写对客服评价，评价成功跳转主页，填写问卷，等等业务，注意观察url。
6. 业务完成后跳转这可以归结为一类跳转，比如修改密码，修改完成后跳转登陆页面，绑定银行卡，绑定成功后返回银行卡充值等页面，或者说给定一个链接办理VIP，但是你需要认证身份才能访问这个业务，这个时候通常会给定一个链接，认证之后跳转到刚刚要办理VIP的页面。
url跳转常用参数
redirecturlredirectUrlcallbackreturn_urltoUrlReturnUrlfromUrlredUrlrequestredirect_toredirect_urljumpjump_totargettogotolinklinktodomainoauth_callback
漏洞危害
攻击者可能会使用Web服务器攻击其他站点；
如果对输出没有做严格限制，将可能导致反射性XSS漏洞；
黑产将利用此漏洞，从信任网站跳转到攻击者构造的恶意网站用来进行钓鱼、诈骗等行为
修复建议
严格控制将要跳转的域名，如果某个业务事先已经确定将要跳转的网站，最稳妥的方式是将其直接编码在源代码中，通过URL中传入的参数来映射跳转网址。
严格验证跳转URL参数的有效性、合法性。
校验传入的URL参数是否为可信域名
0x3 漏洞原理
漏洞原理一：
Url重定向是程序员误信了攻击者的输入而将网站重定向到另一个站点，这通常通过url参数、HTML<meta>刷新标签、DOM中的window对象的location属性来实现的
很多Web 网站都是通过在原始 URL 的参数中设置目标 URL 来有意实现用户访问的重定向的。应用程序通过使用这个参数来告诉浏览器向目标 URL 发送一个GET请求，，例如，假定百度网站具有重定向到 Email 的功能，就可以通过访问如下URL 实现：
https://www.baidu.com/?redirect_to=https://www.Email.com
在这种情况下，当我们访问上面的 URL时，百度网站会接收到一个HTTP 的GET 请求，然后依据 redirect_to 参数中指定的值来确定将你的浏览器重定向到哪里。在这之后，百度 网站服务器会返回一个用于指示浏览器重定向用户的 HTTP响应状态码。通常，这个状态码是302，但有时也可能是 301、303、307 或 308。
这些 HTTP 响应状态码告诉浏览器请求的网页找到了，但是需要浏览器发起一个 GET请求到redirect_to 参数值，https://www.email.com/这个参数值也在HTTP 响应Location 头中。Location 头表示了向哪里重定向 CET 请求。
现在，假设攻击者修改了原始的 URL，如下所示：
https://www.baidu.com/?redirect_to=https://www.diaoyuwangzhan.com
如果百度没有验证 redirect_ to参数是否为其将访问者重定向到一个自有合法站点，攻击者就可以将该参数的值换成它们自己的 URL。
结果是HTTP 响应可能会引导浏览器向 https://www.diaoyuwangzhan.com发起 GET 请求。一旦攻击者已经引导用户到他们的恶意网站，就可以发起进一步的攻击。
漏洞原理二：
HTML<meta>标签和 JavaScript 都可以重定向浏览器。HTML<meta>标签可以告知浏览器刷新网页，并向标签中的content属性定义的URL发起GET请求。
下面是一一个例子:
<meta http-equiv="refresh" content="0; ur1=https://www. Baidu.com/">
content属性定义了浏览器发起HTTP请求的两个步骤。首先，content 属性定义了浏览器在向URL发起HTTP请求前需要等待的时间，在本例中，这个时间是0秒。
其次,content属性确定了浏览器向其发起GET请求的网站中URL的参数，在本例中，这个参数是https://www.baidu.com.
当我们具有控制<meta>标签的content属性的能力时,或者通过其他漏洞能够注人他们自己的标签时，就可以利用这种重定向行为。
漏洞原理三：
JavaScript修改文档对象模型(DOM)中window对象的location属性来实现重定向用户。DOM是用于HTML和XML文档的API.它允许开发者修改网页的结构、风格和内容。
因为location属性表示了请求将被重定向到哪里，浏览器将立刻解释JavaScript脚本并重定向到指定的URL.我们可以通过如下形式的JavaScript脚本修改window的location属性:
window. location = https://www.baidu. com/
window.location.href = htts:/www.baidu.com
window. location.replace(htts://ww. baidu.com)
使用条件：我们必须要拥有执行js的权限才行（获取js权限的方法大家应该知道）
0x4 漏洞猎杀
测试方法与出现位置
方法1：直接观看get请求注意参数
Url= redirect= next= r= u=
方法2：使用Burp查看包含url跳转的get历史请求。
出现地方：登录框的时候抓数据包 直接参加get参数
案例一：
下面这个案例是前段时间我跟我师傅一起研究的一个src的案例，这个URL重定向漏洞还是蛮经典的，是当我我在一个企业的购物商城的卖家后台发现的漏洞，当时我们在浏览时突然发现一个get参数是跳转到货物供应链的：
www.xxx.xxx.com/oauta/authurl/?targeturl=www.gongyinglian.xxx.xxx.cn
我们可以看见参数targeturl?=后面跟着跳转的参数,然后我们将参数修改为www.baidu.com 即可跳转到百度 而百度bai.du的域和这个企业的购物商城的域完全不同了，也就是这样，然后也就是拿到了这个企业商城的一个URL重定向漏洞了。
案例二：
下面这个是这几天我在一个视频播放器的一个应用中找到的这个漏洞，也是一个URL重定向漏洞，下面给师傅们分享下这个漏洞的过程以及宝贵的实战经验哈。
该漏洞场景是对一个视频分享它会生成一个二维码跳转到我们要分享的视频，可我们可以在生成二维码的时候进行抓包导致ur跳转漏洞。
1、首先我这里给分享视频地址生成的二维码
这个分享二维码的url如下：
www.xxx.xxx.com/aiis/h5/pc-client/#/qrcode?url=https%3A%2F%2Fn.com%2Faiis%2FinvestmentAdvisor
2、修改该地址为 https://www.baidu.com 修改完成后，刷新该界面
3、然后就直接使用我们的手机扫描二维码，直接跳转到修改的地址
到以上为止，两个URL重定向漏洞案例都已经分享完成了
0x5 总结
本篇文章主要是先从URL重定向的简介来给大家介绍，然后再给大家介绍下这个漏洞的一些常见的手法以及原理。然后给师傅们详细分析了下URL重定向漏洞原理，希望对师傅们有帮助。
最后面拿了两个真实的实战案例给师傅们分享了一下，主要是分享URL重定向更改它的URL，然后以www.baidu.com 为例，给师傅们演示下这个跳转的过程。
最后，希望这篇文章对师傅们有帮助，关注我，下次给师傅们分享更多的实战案例！！！
文章中涉及的敏感信息均已做打码处理，文章仅做经验分享用途，切勿当真，未授权的攻击属于非法行为！文章中敏感信息均已做多层打码处理。传播、利用本文章所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，作者不为此承担任何责任，一旦造成后果请自行承担！
原文作者：Wsec
原文连接：https://xz.aliyun.com/t/15069
推 荐 阅 读
横向移动之RDP&Desktop Session Hija
