挖掘src之url跳转以及延伸

  • A+

前段时间待在家一直没事,挖了挖src练练手,初挖src,没有什么厉害的洞,捡了一些url跳转。
url跳转,一些常用的绕过方式在百度可以看到,比如一些符号:?、#、.等,这里不再说明。下面我来说说遇到过的src的url跳转类型

0x01跳转类型

1.无任何措施

1.png
直接通过jumpurl参数,来进行url跳转,可以直接跳转到百度(Location:http://www.baidu.com)
原因可能在于该点未对jumpurl参数校验,所以会对jumpurl传入的参数直接进行Location跳转

2.对参数进行部分校验

image.png
蓝色框:原来跳转域名,举例:example.test.com
红色框:原跳转域名的主域名,举例:test.com
这里为什么说部分校验,如果和①情况的话,是跳转不了的,直接报错。可以进行以下绕过,在原域名前面加上668btest.com#@(#为锚链接)据我推测,可能校验的代码是如下代码:(以Python举例)
if 'test.com' in url:
print("允许跳转")

所以如果跳转参数为668btest.com是符合逻辑的

3.对双斜杠进行过滤

image.png

image.png

可以看到双斜杠直接跳到原来的域名,下面这张单斜杠其实已经可以进行跳转了(firefox、chrome、safari测试成功),然而后面我看了《白帽子讲web安全》以后,对浏览器解析的字符有了一点了解,这里举一个简单例子,如果参数是http:/\www.baidu.com

image.png
谷歌测试能正常跳转baidu

image.png
firefox测试能正常跳转baidu

image.png
但是safari却不行

image.png
这里我猜测可能是safari识别不了参数里含有/\的url跳转,导致Location失败,致使无法打开页面(直接让safari打开http:/\www.baidu.com是可以的)如果不对还请指教,更多的浏览器识别畸形还请看《白帽子讲web安全》
这里还要讲一点,这个Location为服务端的redirect

image.png
本地测试meta的跳转,没有Location属性:

image.png
所以我推测,服务端另外设置了Location跳转,并不仅仅只有meta的跳转;如果没有Location跳转,可能还可以延伸出xss

4.某个特定参数取值决定跳转

image.png
该类型为补充,只有service_type的值为1015的时候才会跳转,其他为1、2、3则不跳转

5.url跳转可能引发的凭证劫取

该例洞发现的时候建立在②类型基础上:

image.png

红色框:原跳转域名的主域名,举例:test.com
%23%40为#@的url编码,111test.com即为跳转域名,可以看到这个页面还有个referer头
如果按照一般来说,下个页面进行跳转的话,referer头是不会带入的,但是,这里跳转为Location,referer参数自动带入下一个页面
Follow redirection后可以看到:

image.png
可以搭建一个web服务器,来记录Referer头带入的东西
能获取到Referer的情况:
①. 使用标签来访问页面
②. submit提交的表单post和get
③. 使用js提交的post和get表单

不能获取的Referer的情况:
①. 使用js重定向 location.href 和 location.replace()
②. 服务器端的redirect,PHP中的header(“location:”)
③. 使用http重定向

6.超链接带入url的跳转

image.png
该处为src下载apk的地址,红色框为我构造的一个服务器的apk安装包,蓝色框为点击事件请求红框的url,所以url跳转带入了恶意apk,对apk进行伪装,可以达到钓鱼效果,控制受害者的手机

image.png

0x02防护

1.白名单校验是最好的方式,信任域之间可以跳转

2.代码控制跳转,不在参数中显示

3.添加恶意链接检测