xss-labs靶场总结（持续更新）

1.level1

观察该页面的URL，可以发现它向服务器提交了一个name参数，值为“test”；再观察页面可得它将name参数的值显示在了页面上，而且还显示了字符的长度。
观看页面源码，可以发现该关为反射性xss。

但是这里无法确认服务器端有没有对这其中的特殊字符串进行过滤，可以在name参数中提交一些特殊的字符串以及<script>标签，然后再查看页面源码，发现并没有过滤.

当然也可以构造一个小小的弹窗

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

想要更深层次的查看可以去看服务器端的level1.php是如何对我们传入的参数进行处理的

2.level2

从url入手开始看，依然是get方式传递参数，应该还是反射型xss

我们还是像第一关一样，去构造弹窗并提交，但是并没有达到预期的效果，查看页面源码
可以看到在

标签之中的恶意代码被编码了。
其中<和>都被编码成了html字符实体。

猜测服务器端使用了htmlspecialchars()函数对我们输入的值进行了处理

再往下查看，可以看到插入到value参数值中的恶意代码并没有被编码而是直接原样返回
但是问题是这里的js代码在标签属性值中，浏览器是无法执行的。既然上面的恶意代码被编码了，那么只能从属性值中的恶意代码处进行突破了。

要想浏览器执行这里的弹窗代码，只需要将属性的引号和标签先闭合就可以了。将keyword的值重新进行赋值"><script>alert('xss')</script>//

3.level3

输入一些简单的字符串然后查看页面源码，发现和第二关差不多
构造弹窗，发现并没有达到预期的效果，查看页面源码
发现输入的两个尖括号又被实体化了，而且value也被进行了实体化的处理，去服务器端查看其后端源码
我们猜测这里可以通过标签的一些特殊事件来执行js代码，构造如下：

level3.php?keyword='οnfοcus=javascript:alert('xss') > //&submit=搜索

发现没有直接弹窗，这是因为onfocus事件的特殊性造成的

onfocus 事件在对象获得焦点时发生。
onfocus 通常用于 <input>, <select>, 和<a>.

那么什么是对象获得焦点呢：
最简单的实例就是网页上的一个输入框,当使用鼠标点击该输入框时输入框被选中可以
输入内容的时候就是该输入框获得焦点的时候,此时输入框就会触发onfocus事件.因此
点击当前页面的输入框就可以完成弹框了。

4.level4

这一关很明显还是用的get方式请求参数，而且我们的输入在该页面上还有两处显示
还是输入我们上面用到的payload，然后查看页面源码
发现服务器端程序对h标签中的内容做了实体化，而且删除了输入框中的尖括号

事件触发是不需要这两个括号的，所以把上一关的payload搬下来进行输入就可

level4.php?keyword="onfocus=javascript:alert('xss')//

5.level5

分析页面，发现这是get方式去提交参数的，所以还是反射性xss。
提交弹窗代码：

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

发现并没有出现弹窗，查看页面源码
发现：h标签处，还是对两个尖括号进行了实体化的处理，并且在value值中对script加了一个’_'符号。
构造一个不含script标签的语句：

?keyword="onfocus=javascript:alert('xss')>//

发现没有出现弹窗，继续查看源码，发现也对onfocus这一类的事件字符做了一样的处理，但是没有对JavaScript字符进行过滤或者转义，所以构造如下语句：

?keyword="> <a href=javascript:alert('xss') > xss</a> //

发现出现了弹窗。

想要进一步理解其原理，去看服务器端的源码

6.level6

随便输入，然后查看后端源码，发现和之前的一样，都是在h标签中有一次的输出，在value属性中有一次输出，构造特殊语句：

<script>alert(‘xss’)</script>

查看页面源码，发现和上一关一样
插入：

?keyword="οnfοcus=javascript:alert('xss')"

处理方式发现还是和上一关一样

?keyword="> <a href=javascript:alert('xss') > xss</a> //

也失败，查看源码一样的原因
试试大小写是否能绕过：

?keyword="> <a HrEf=javascript:alert('xss') > xss</a> //

发现成功了
注：HTML是对大小写不明感的。
查看后端源码，这一关的防范措施应该是到这里为止最多的

有一处地方是对src进行匹配处理的，这里就得提到img这个标签了
熟悉html的人都会知道在标签中引用图片会用到一个属性就是src。正常的引用图片就是将待引用图片的地址赋值给src属性。但是在js中如果src属性的值不正常或者无法访问到时就可以触发一个onerror事件来执行js代码。
所以payload就可以这样编写：

?name=<img src=111 onerror=alert('xss')>

7.level7

用先前的payload进行测试，然后查看页面源码。
发现主要有一下几种保护措施：对<和>进行编码处理；将script字符直接删除；onfocus事件直接把on字符删除了；javascript中的script字符也被删除了；大小写也不能绕过，所以这里尝试一下双写关键字

发现对关键字双写可以绕过，查看页面源码发现双写关键字可以绕过的原因是对关键字删除的代码只会执行一次

8.level8

提交的参数值一个会插入到<input>标签的value属性值中，一个会插入到下方<a>标签的href属性值中
测试服务器端的处理，输入弹窗口的那个payload，发现value中的两个尖括号实体化了，href属性值中script字符被插入了_字符破坏语义。

事件触发测试：?keyword="  onfocus=javascript:alert('xss')>//

用来闭合引号的引号也被编码了。
onfocus一类的事件也被破坏了
大小写绕过，失败了
因为此处没有对关键字进行删除，所以就不进行双写测试了

其实还可以将我们要提交的js代码进行编码

javascript:alert('xss')

对其进行编码后可以发现能够成功绕过，而且顺利弹窗

9.level9