xss类型:反射型，存储型，DOM型
反射型：
利用网站的漏洞，通过某些方式让受害者在他的客户端上运行payload，从而实现攻击
不过执行要有前提，不是一定成功，所以一般是对于特殊群体比如一个在固定时间用固定浏览器做固定的事情的群体，你发点钓鱼连接或者包装一下，让他在合适的时机点击才有用（要求相对高，危害相对小）
一：受害者必须是出于出问题网站的登录状态运行的含有payload的请求或者命令，不然没用
二：必须是同一个浏览器（Edge，Chrome，FireFox...）且不能是无痕模式，不然也不行
不同浏览器之间cookie完全隔离，无痕模式也是，导致无法正常执行
存储型：
利用网站的漏洞，让payload存储在后端中，只要别人的客户端加载了那一部分就会执行恶意payload到达目的，相比反射型xss更加稳定，因为对方看到的时候已经满足了反射型的那两个主要条件，如果可以长期存储在后端，危害巨大。
例子：博客的评论，你在评论区写点恶意代码，然后后端会存到数据库中，当别人看的时候别人的客户端就会执行恶意代码从而达到目的（偷cookie盗号，让你转发消息....）
DOM型：
这个类型和上面两种不同，上面两种在某种意义上可以说是旧时代的遗物，在15年左右发生的大规模前后端分离，在那之前大部分的活都是后端干，前端就负责写个模版，后端要根据模版结合数据来渲染出完整的html文件返回到浏览器，相当于前端就是个展示加上写个模版，绝大部分最可能出错的地方都在后端，因为后端干了大部分的活，耦合性高，内部代码复杂，所以安全隐患集中在后端，所以那时候的xss漏洞反射型和存储型占主要，几乎没有DOM型。
而在前后端开始分离后，网络架构大概被分成了 前端 后端 接口 ，在此时前端负责独立渲染页面只通过接口从后端得到数据，剩下的全是靠前端自己，所以此时就出现了因为前端代码不严谨导致的恶意代码在前端执行没有经过后端，导致的xss漏洞
在前后端分离后DOM型占比猛涨，主要是因为前端对于输入的过滤不严格，尤其是特殊字符，把用户的输入当命令执行，后端也要过滤，不过相对说DOM型是前端出的问题，后端因为就是接受请求返回个数据，我认为所以相对好过滤，毕竟就是通过API接口接受的数据相对来说干净的多（现实情况就不清楚了，反正DOM的挺多是真的，尤其是全部或者绝大部分由前端处理渲染的页面就很有可能出现）
dvwa里DOM xss的各难度的小总结
low：
完全没过滤，直接就是<script>alerrt(1)</script>
medium：
把<script>（无论大小写，双写什么的也绕不过去）给过滤了，那就换一个<img src=1 onerror=alert(1)>，也不行，然后发现payload在<select>下的<option>标签里，<option>里的所有标签都被会当成<option>标签的内容而不是一个标签去执行，而<select>里只能嵌套<option>，所以得把前面的<option><select>全都闭合了，然后执行<img>就没问题了
payload：</option></script><img src=1 onerror=alert(1)>
high：
后端用了白名单+重定向，这没什么问题，主要是在前端（好像DOM型的都是前端的问题，哈哈哈哈哈），前端稍微有点畜生其实，不过先补充一下关于url的小知识
URL有几个分界点
1.前面的协议，http，https
2.域名路径hostname/:port/path
3.问号？之后是作为Get或者Post请求
#和它后面的部分只留在浏览器本地并不会发送到后端，有一些它自己的作用
++根据上面说的，如果只改#和后面的东西，客户端是不会向后端发送请求的，#和后面的东西就不会执行，页面也就不会改变，所以要重新加载后才会有弹窗++
而high也就是因为前端用危险函数location.herf直接截取url，也就是把#后面的也截取走作为内容，然后又用了一个document.write危险函数让内容可以作为html命令执行，从而运行了#和后面的内容导致了xss漏洞，所以只要在#后面插点payload就可以了，#本身不会到后端，相当于绕过了后端不会触发重定向，然后前端危险的提取内容以及执行方法导致了这个漏洞
payload：#<script>alert(1);</script>
high其实完全是前端自己作死，后端白名单+重定向没问题，只要在前端用一点严格的函数来进行过滤就可以避免