Pikachu-XSS

第1关 反射型xss(get)

拿到一个xss漏洞，首先就是插入一个script代码试试。所以这里我们插入一个<script>alert(1)</script>，输入的时候发现前端输入框做了长度限制。

emmm…大概能猜到此题的考察点了，绕过前端的方法有很多，这里举两种常见的例子：

（1）浏览器地址栏输入

因为输入的payload会在地址栏显示，而地址栏是没有做限制的。

（2）直接修改html代码

F12唤出开发者直接修改html代码。把maxlength=20改成maxlength=100，长度够用就行。

第2关 反射型xss(post)

这关进去是个登录界面，刚开始还认为漏洞是在这两个框的其中一个，于是随便输了用户名和密码试了一下，心想输入回显到页面上的应该是注入点，结果发现两个都没有回显…

点了右边提示一看要先用admin账号密码登录，于是通过所给的账号登录后，得到一个提交页面，感觉和上一关差不多。。而且这关的输入框还没有长度限制。

构造payload：

<script>alert(document.cookie)</script>

第3关 存储型xss

这关进去是个留言板。

构造payload：

<img src=1 onerror=alert(1) >

提交后直接弹窗 ，并且留言列表下面多了一条信息。

下面就是见识存储型XSS威力的时候了，在另外一个客户端浏览器中来到本关页面，也出现了同样的弹框。说明存储型XSS能危害所有访问受影响页面的用户。

第4关 DOM型xss

进入第四关发现又是只有一个输入框，所以我们直接输入<script>alert(1)</script>试试，输入后发现回显了一个链接名为what do you see，鼠标右键–显示网页源代码，Ctrl+F弹出搜索框，输入what do you see瞅瞅，找到了一段js代码，寻找DOM XSS的本质就是做js阅读理解题。

分析代码可以得出，这里利用了DOM将字符串进行了拼接并把值给a标签的href，然后输出一个what do you see?

构造payload：

 ' onclick="alert(/xss/)">

代码执行流程如下：

通关成功！

第5关 DOM型xss-x

进入第五关发现也是一个输入框，在输入框中输了个“吃瓜”，提交之后发现吃瓜群众跑到url里面去了（这就是和上一关的不同），然后多出来个链接“有些费尽心机想要忘记的事情,后来真的就忘掉了”

既然还是DOM型，就鼠标右键–显示网页源代码

分析代码可以得出这题跟第4题没啥区别，也是利用了DOM将字符串进行了拼接并把值给a标签的href，就是比第4题更容易利用而已

构造payload：

 ' onclick="alert(/xss/)">

代码执行流程如下：

通关成功！

题外话：因为本关payload在url中，所以比第4关好利用很多；DOM型XSS只在前端，与后端毫无关系；DOM-X型危害更大，它能够像反射型一样在URL中体现，将URL发给了受害者就能进行攻击。

第6关 xss之盲打

进入第六关后发现是一个留言板，随便输入点东西，提交之后发现输入的东西完全不显示在页面上，去哪儿了呢？

查看网页源代码之后，发现本关的输入是以POST方法提交的，但是form标签里没有action属性，也不知道表单数据被提交到哪去了。

点击提示发现，原来这关需要登录才能进行xss利用。

跳转到所给页面后，通过提示给的账号密码进行登录。

登录后发现我们之前输入的内容已经记录在后台。

而且内容和用户名都有回显，所以对两个输入框都进行测试。

构造payload：

// 输入框一
<script>alert(/xss/)</script>
// 输入框二
<script>alert(document.cookie)</script>

登录后台，发现输入的payload触发了两次，所以说明两个输入框都存在xss注入。

第7关 xss之过滤

随便输入一些内容，提交之后发现页面有回显输入的内容，url中也有输入的内容，离开本页面再回来，页面就没有这个内容了，说明是反射型GET型XSS

来一发最常见的payload：

<script>alert(1)</script>

发现只返回一个'>'

大胆猜测一下后端过滤的正则有可能是：

抱着好奇心，去后台看了一下源码：

emmm…略微有些偏差😅不过无伤大雅，既然没有过滤其他标签，那我们就用a标签进行绕过。

构造payload：

<a herf="xss" onclick="alert(document.cookie)">

通关成功！

第8关 xss之htmlspecialchars

按照惯例，继续在输入框来一发常见payload ：

<script>alert('xss')</script>

根据回显的内容，再结合网页源代码进行分析。

由上可知，输入的payload被拼接到a标签的href里面了，而且还被htmlspecialchars函数进行了转义。

htmlspecialchars()函数把一些预定义的字符转换为HTML实体。 
预定义的字符是： 
& （和号）成为 & 
" （双引号）成为 "	 
' （单引号）成为 ' （默认配置是不过滤单引号）
< （小于）成为 &lt; 
> （大于）成为 &gt;

这里可以从两个维度出发，去构造绕过的payload。

（1）利用js伪协议，构造payload：

javascript:alert(document.cookie)

（2）闭合herf使用其他属性，构造payload：

xss' onclick='alert(document.cookie)

第9关 xss之href输出

按照惯例，继续在输入框来一发常见payload ：

<script>alert('xss')</script>

根据回显的内容，再结合网页源代码进行分析。

右上可知，跟第八关一样，还是进行了转义过滤，不过多了个单引号的过滤，所以直接用js伪协议绕过即可。

构造payload：

javascript:alert(document.cookie)

思考：

当用户输入由href属性输出时，该怎么防御xss呢？

仅仅html编码就不够了，本关的php源代码中给了提示（有点简略，这里稍微扩充一点）。遇到这种情况，需要两点处理：

1、检查用户输入，必须以http或者https开头。注意，不可以仅仅是包含http和https；

2、进行html实体编码；

第10关 xss之js输出

按照惯例，继续在输入框来一发常见payload ：

<script>alert('xss')</script>

无回显，鼠标右键–显示网页源代码，刚刚输入的东西跑到<script>标签内了，并且没有被编码

接下来就很简单了，只要无中生有出一个js语句就好了，首先要用’;闭合掉当前的语句，然后插入新语句，最后再用//注释掉老语句遗留下来的’;

构造payload：

';alert(document.cookie);//

通关成功！