介绍
👏 Hi! 我是 Yumuing，一个技术的敲钟人
👨💻 每天分享技术文章，永远做技术的朝拜者
📚 欢迎关注我的博客：Yumuing's blog
跨站脚本（Cross-site scripting，简称为：CSS, 但这会与层叠样式表（Cascading Style Sheets，CSS）的缩写混淆。因此，跨站脚本攻击缩写为XSS）是一种网站应用程序的安全漏洞攻击。
XSS 攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上也可以包括 Java、 VBScript、ActiveX、 Flash 或者甚至是普通的HTML。攻击成功后，攻击者可能得到包括但不限于更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。
其原理就是服务器对用户提交的数据过滤不严，导致浏览器把用户的输入当成了JS代码并直接返回给客户端执行，从而实现对客户端的攻击目的。
XSS 分类
最常见的几种分类：反射型（非持久型）XSS、存储型（持久型）XSS、DOM型XSS、通用型XSS、突变型XSS。
反射型（非持久型）
反射型XSS，又称非持久型XSS，攻击相对于受害者而言是一次性的，具体表现在受害者点击了含有的恶意JavaScript脚本的url，恶意代码并没有保存在目标网站，而Web应用程序只是不加处理的把该恶意脚本“反射”回受害者的浏览器而使受害者的浏览器执行相应的脚本。
成因
当用户的输入或者一些用户可控参数未经处理地输出到页面上，就容易产生XSS漏洞。主要场景有以下几种：
- 将不可信数据插入到HTML标签之间时；// 例如div, p, td；
- 将不可信数据插入到HTML属性里时；// 例如：
<div width=$INPUT></div> - 将不可信数据插入到SCRIPT里时；// 例如：
<script>var message = ” $INPUT “;</script> - 还有插入到Style属性里的情况，同样具有一定的危害性；// 例如
<span style=” property : $INPUT ”></span> - 将不可信数据插入到HTML URL里时，// 例如：
<a href=”[http://www.abcd.com?param=](http://www.ccc.com/?param=) $INPUT ”></a> - 使用富文本时，没有使用XSS规则引擎进行编码过滤。
对于以上的几个场景，若服务端或者前端没有做好防范措施，就会出现漏洞隐患。
测试方案
在黑盒测试中，这种类型比较容易通过漏洞扫描器直接发现，我们只需要按照扫描结果进行相应的验证就可以了。相对的在白盒审计中， 我们首先要寻找带参数的输出函数，接下来通过输出内容回溯到输入参数，观察是否过滤即可。
存储型（持久型）
存储型XSS是指应用程序通过Web请求获取不可信赖的数据，在未检验数据是否存在XSS代码的情况下，便将其存入数据库。当下一次从数据库中获取该数据时程序也未对其进行过滤，页面再次执行XSS代码持续攻击用户。存储型XSS漏洞大多出现在留言板、评论区，用户提交了包含XSS代码的留言到数据库，当目标用户查询留言时，那些留言的内容会从服务器解析之后加载出来。
成因
存储型XSS漏洞的成因与反射型的根源类似，不同的是恶意代码会被保存在服务器中，导致其它用户（前端）和管理员（前后端）在访问资源时执行了恶意代码，用户访问服务器-跨站链接-返回跨站代码。
DOM型（非持久型）
DOM，全称Document Object Model，是一个平台和语言都中立的接口，可以使程序和脚本能够动态访问和更新文档的内容、结构以及样式，DOM-XSS简单理解就是不与后台服务器产生数据交互，是一种通过DOM操作前端代码输出的时候产生的问题。也就是通过修改页面的DOM节点形成的XSS，称之为DOM Based XSS。
成因
DOM型XSS是基于DOM文档对象模型的。对于浏览器来说，DOM文档就是一份XML文档，当有了这个标准的技术之后，通过JavaScript就可以轻松的访问DOM。当确认客户端代码中有DOM型XSS漏洞时，诱使(钓鱼)一名用户访问自己构造的URL，利用步骤和反射型很类似，但是唯一的区别就是，构造的URL参数不用发送到服务器端，可以达到绕过WAF、躲避服务端的检测效果。
通用型XSS
通用型XSS，也叫做UXSS或者Universal XSS，全称Universal Cross-Site Scripting。
上面三种XSS攻击的是因为客户端或服务端的代码开发不严谨等问题而存在漏洞的目标网站或者应用程序。这些攻击的先决条件是访问页面存在漏洞，但是UXSS是一种利用浏览器或者浏览器扩展漏洞来制造产生XSS的条件并执行代码的一种攻击类型。
成因
Web浏览器是正在使用的最流行的应用程序之一，当一个新漏洞被发现的时候，不管自己利用还是说报告给官方，而这个过程中都有一段不小的时间，这一过程中漏洞都可能被利用于UXSS。
不仅是浏览器本身的漏洞，现在主流浏览器都支持扩展程序的安装，而众多的浏览器扩展程序可能导致带来更多的漏洞和安全问题。因为UXSS攻击不需要网站页面本身存在漏洞，同时可能访问其他安全无漏洞页面，使得UXSS成为XSS里危险和最具破坏性的攻击类型之一。
突变型XSS
突变型XSS，也叫做mXSS或，全称Mutation-based Cross-Site-Scripting。（mutation，突变，来自遗传学的一个单词，大家都知道的基因突变，gene mutation）
成因
然而，如果用户所提供的富文本内容通过javascript代码进入innerHTML属性后，一些意外的变化会使得这个认定不再成立：浏览器的渲染引擎会将本来没有任何危害的HTML代码渲染成具有潜在危险的XSS攻击代码。
随后，该段攻击代码，可能会被JS代码中的其它一些流程输出到DOM中或是其它方式被再次渲染，从而导致XSS的执行。 这种由于HTML内容进入innerHTML后发生意外变化，而最终导致XSS的攻击流程。
XSS 的预防
网上防范XSS攻击的方法一搜就一大堆，但是无论方法有多少，始终是万变不离其宗。
XSS 攻击有两大要素：
攻击者提交恶意代码。
浏览器执行恶意代码。
那基本的解决思路就很清晰了，做好过滤以及错误执行的预防措施，下面说明一些基本的预防思路：
- 输入过滤：不单单前端过滤数据请求，后端再执行方法时，也需要先进行过滤判断，以防止恶意代码出现的可能，每个输入端都要进行判断，才可能正常使用，不要相信任何一个请求，如将不可信的值输出 URL参数之前，进行 URLEncode操作，而对于从 URL参数中获取值一定要进行格式检测（比如你需要的时URL，就判读是否满足URL格式）。
- 前端渲染代码数据分离：渲染过程中，必须防止内联样式和多种代码相互混合的情况。必须明确地告知浏览器设置的内容具体格式是什么？如文本（.innerText）、属性（.setAttribute）等等，浏览器不会被轻易的被欺骗，执行预期外的代码了。
- 代码转义：如需进行拼接字符，就必须使用相应的转义库，把一些恶意代码进行转义，化成良好代码。
- Cookie 防护：对重要的 cookie设置 httpOnly, 防止客户端通过document.cookie读取 cookie，此 HTTP头由服务端设置。
- 使用安全方法：如不要使用 Eval来解析并运行不确定的数据或代码，对于 JSON解析请使用 JSON.parse() 方法。
防范 XSS 是不只是服务端的任务，需要后端和前端共同参与的系统工程。虽然很难通过技术手段完全避免XSS，但我们原则上减少漏洞的产生。
测试网站推荐
初学xss，最好的靶场莫过于xss-labs和xssaq。
