XSS（跨站脚本）概述以及pikachu上的实验操作
Cross-Site Scripting 简称为“CSS”，为避免与前端叠成样式表的缩写"CSS"冲突，故又称XSS。
XSS漏洞一直被评估为web漏洞中危害较大的漏洞，在OWASP TOP10的排名中一直属于前三的江湖地位。
XSS是一种发生在前端浏览器端的漏洞，所以其危害的对象也是前端用户。
形成XSS漏洞的主要原因是程序对输入和输出没有做合适的处理，导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。
一般XSS可以分为如下几种常见类型：
1.反射型XSS
交互的数据一般不会被存储在数据库里，一次性，所见即所得，一般出现在查询类页面等。
2.存储型XSS
交互的数据会被存储在数据库里面，永久性存储，一般出现在留言板，注册等页面。
3.DOM型XSS
不与后台服务器产生数据交互，是一种通过DOM操作前端代码输出的时候产生的问题，一次性也属于反射型。
XSS漏洞测试流程：
第一步：在目标站点上找到输入点，比如查询接口，留言板等；
第二步：输入一组“特殊字符+唯一识别字符”，点击提交，查看返回的源码，是否有做对应的处理；
第三步：通过搜索定位到唯一字符，结合唯一字符前后语法确认是否可以构成执行js的条件（构造闭合）；
第四步：提交构造的脚本代码（以及各种绕过姿势），看是否可以成功执行，如果成功执则说明存在XSS漏洞
一，反射型XSS实验演示
漏洞形成原因：后台代码从输入到输出都没有进行一个防XSS漏洞的过滤
首先打开pikachu平台的反射型XSS页面，在对应的输入点输入‘“<>6666点击提交
接着查看页面源码，ctrl+F搜索我们刚刚输入的字符6666找到输出点，我们可以看到我们刚才输入的字符被原封不动输出到p标签，
接着尝试输入一段正确的js代码，看是否也会被原封不动的返回，返回页面在输入点上输入<script>alert('xss')</script>（ps：这里我们会发现输入点限制了输入长度我可以通过web控制台修改输入长度）
输入完之后点击提交，成功弹出窗口，但刷新页面之后弹窗就不会出现了
证明这里存在一个反射型的XSS漏洞
二，存储型XSS实验演示
漏洞形成原因：从数据库中输出时没有进行过滤和转译，原封不动的输出到了前端浏览器中
首先打开pikachu的存储型XSS页面，我们先在留言板上随意留言，发现留言会被存储在页面上刷新之后也会在页面上
接着进行XSS测试流程，先输入一段特殊字符'"<>?&66666点击提交
发现我们输入的字符被直接当做留言给显示输出来了，然后我们直接去查看页面源码，ctrl+F搜索我们刚才输入的字符66666找到输入点，
可以看到我们刚才输入的字符被直接输出到p标签里面，没有做任何的过滤和转译的处理，接下来我们就输入一个正确的js代码<script>alert('xss')</script>
弹出弹窗，刷新之后也仍然弹出，因为这段代码被存储到数据库中，每次访问都会被执行
三，DOM型XSS实验演示
首先要明白什么是DOM
DOM可以理解为理解为一个一个访问HTML的标准的编程接口，通过这个接口我们可以直接用js在前端对html文档进行操作
我们点开pikachu的DOM型XSS页面，随意输入一段字符点击提交弹出了一个what do you see？的提示，接着我们查看源码看看具体流程。
ctrl+F搜索what找到相关的点，是一段js代码，分析下来我们发现这段代码用DOM里面的getELemeById在input中获取到了我们输入的内容，接着将获取到的内容用字符串拼接的方式写到了a标签的herf属性里面
之前我们接触的反射型和存储型都是后台接收到数据然后再输出到前台，而这里我们输入的内容被前端用DOM的getELemeById直接获取到了，再用一个div输出了
接着我们复制a标签的内的输出的代码构造一个闭合函数<a href='#'onclick="alert(xss)">'>what do you see?</a>
将除了源代码内有的其余部分#'onclick="alert('xss')"复制到输入框中，点击提交，弹出弹框
接着我们来看看DOM型XSS-s
和之前的操作一样。先随意输入一些字符，再点开页面源码，找到相关的代码，看看是怎么一个逻辑，简单分析我们发现这段代码和之前的代码大体相同唯一的不同就是他的输入是从浏览器的URL获取的，这个就和反射型的XSS很像了漏洞形成的输入点都是在URL里面
同样的我们来构造闭合函数，其实和刚才的闭合一样我们将闭合函数代码输入进去点提交，连续点击提示，跳出弹窗。
