前段时间待在家一直没事，挖了挖src练练手，初挖src，没有什么厉害的洞，捡了一些url跳转。 url跳转，一些常用的绕过方式在百度可以看到，比如一些符号:?、#、.等，这里不再说明。下面我来说说遇到过的src的url跳转类型
0x01跳转类型
1.无任何措施
直接通过jumpurl参数，来进行url跳转，可以直接跳转到百度(Location:http://www.baidu.com)
原因可能在于该点未对jumpurl参数校验，所以会对jumpurl传入的参数直接进行Location跳转
2.对参数进行部分校验
蓝色框：原来跳转域名，举例：example.test.com
红色框：原跳转域名的主域名，举例：test.com
这里为什么说部分校验，如果和①情况的话，是跳转不了的，直接报错。可以进行以下绕过，在原域名前面加上668btest.com#@(#为锚链接)据我推测，可能校验的代码是如下代码：(以Python举例)
if 'test.com' in url:
print("允许跳转")所以如果跳转参数为668btest.com是符合逻辑的
3.对双斜杠进行过滤
可以看到双斜杠直接跳到原来的域名，下面这张单斜杠其实已经可以进行跳转了(firefox、chrome、safari测试成功)，然而后面我看了《白帽子讲web安全》以后，对浏览器解析的字符有了一点了解，这里举一个简单例子，如果参数是http:/\www.baidu.com
谷歌测试能正常跳转baidu
firefox测试能正常跳转baidu
但是safari却不行
这里我猜测可能是safari识别不了参数里含有/\的url跳转，导致Location失败，致使无法打开页面(直接让safari打开http:/\www.baidu.com是可以的)如果不对还请指教，更多的浏览器识别畸形还请看《白帽子讲web安全》
这里还要讲一点，这个Location为服务端的redirect
本地测试meta的跳转，没有Location属性：
所以我推测，服务端另外设置了Location跳转，并不仅仅只有meta的跳转；如果没有Location跳转，可能还可以延伸出xss
4.某个特定参数取值决定跳转
该类型为补充，只有service_type的值为1015的时候才会跳转，其他为1、2、3则不跳转
5.url跳转可能引发的凭证劫取
该例洞发现的时候建立在②类型基础上：
红色框：原跳转域名的主域名，举例：test.com
%23%40为#@的url编码，111test.com即为跳转域名，可以看到这个页面还有个referer头
如果按照一般来说，下个页面进行跳转的话，referer头是不会带入的，但是，这里跳转为Location，referer参数自动带入下一个页面
Follow redirection后可以看到：
可以搭建一个web服务器，来记录Referer头带入的东西
能获取到Referer的情况：
①. 使用标签来访问页面
②. submit提交的表单post和get
③. 使用js提交的post和get表单
不能获取的Referer的情况： ①. 使用js重定向 location.href 和 location.replace() ②. 服务器端的redirect，PHP中的header(“location:”) ③. 使用http重定向
6.超链接带入url的跳转
该处为src下载apk的地址，红色框为我构造的一个服务器的apk安装包，蓝色框为点击事件请求红框的url，所以url跳转带入了恶意apk，对apk进行伪装，可以达到钓鱼效果，控制受害者的手机
