你真的了解XSS漏洞吗(上)

XSS是Web安全中的常见漏洞，也是各位安全从业者刚入门时就会学习的漏洞。但从入门直到入行，还会有人对XSS漏洞一知半解，或者说对于其深入知识知之甚少。本篇文章将会涵盖绝大部分XSS漏洞的专业知识，从漏洞的基础开始，在自动化、绕过、利用手段、防御姿势等多个方面进行工业级的深入探讨。
一图胜千言，下图涵盖了本篇文章包涵的所有知识点：

图片说明

一、基础知识

从基础讲起，让我们回顾一下XSS的基础知识。XSS是一种触发点在前端的漏洞，它的一切都围绕着html、css与javascript展开。有人说XSS实际上是一种html的注入，其实这不全对，XSS也可能是javascript的注入，这一点会在后面的bypass阶段提现的淋漓尽致。当然，不论触发方式是什么，XSS的最终目的都是在受害者浏览器上执行任意javascript代码。
XSS可以简单的分为持久型XSS和非持久型XSS，但如果从漏洞成因和特点来看，可以单独列出四类：反射型XSS、存储型XSS、DOM型XSS以及富文本XSS。

1.1 反射型XSS

安全圈前两年有一句很火的话：『反射型XSS，忽略！』这句话的来源于当向各大厂商提交反射型XSS漏洞时，往往会因为漏洞危害过低而忽略。
这是因为反射型XSS是一种被动式的攻击：黑客将恶意代码写在url中，诱骗用户点击，从而触发漏洞。这种攻击充满了不确定性，加上恶意代码就明晃晃的暴露在url中，会引起人的警惕性，导致攻击成本提高。
图
反射型XSS的攻击原理图如上图所示，恶意代码<svg onload=alert(1)>作为请求中某个字段的值提交到后端后，由于后端未经安全处理，导致返回的html中携带了完整的<svg onload=alert(1)>，从而引发XSS弹框。
当然，上述只是很常见的Get请求的反射型XSS，近两年Post请求的反射型XSS逐渐多了起来。
图
其根本原理如上图所示，漏洞出发的原理是相同的，关键在于如何携带恶意代码发起Post请求。Post XSS结合CSRF漏洞很好的解决了这一问题：诱骗让用户点击某个恶意链接，通过CSRF漏洞发起一个Post请求，请求中带有恶意代码<svg onload=alert(1)>，由于后端未经安全处理，导致返回的html中携带了完整的<svg onload=alert(1)>，从而引发XSS弹框。
Post XSS击中的是开发者的盲点，可能一些开发者仅重视在Get请求处防御XSS漏洞，这一点是在漏洞挖掘过程中可以加以关注的。

1.2 存储型XSS

存储型XSS相对来说危害会更大，一般的厂商会给存储型XSS中危的评级，这是因为存储型XSS攻击较隐蔽，无需点击特制的恶意链接，当用户正常浏览时即可触发，如经典场景留言板：在留言板中插入一条带有恶意代码的留言，这样所有访问此留言板的人都会触发恶意代码。
存储型XSS在代码中并非一步到位，首先，恶意代码会被存入数据库中，当用户浏览时，将恶意代码从数据库中取出放入html中，从而引发XSS漏洞。攻击原理图如下所示：
图
这本质上是信任边界不清晰所导致的漏洞：用户输入存入数据库时，确保其不会产生SQL注入漏洞；认为从数据库中取出的数据是安全的，不进行任何处理直接输出到前端。两个步骤分开看似都是没问题的，然而合到一起就会产生漏洞。其实，数据库中的数据和用户输入都是处于信任边界之外的，需要进行安全处理。

1.3 DOM型XSS

『DOM型XSS与反射型XSS有什么不同？』这是在面试中经常会问到的一个问题。
DOM型XSS的特征和危害与反射型XSS是完全相同的，唯一的区别是：反射型XSS的值先请求到后端，后端未经处理又输出到前端；DOM型XSS的值不会请求到后端，是通过纯前端的javscript代码触发的。
比如一个搜索的场景，下图中『搜索结果如下 "恶意代码"』中的『恶意代码』是直接由javascript从地址栏中取值并赋予的，概念代码如下：

//从地址栏中获取要搜索的词语
var url = location.href;
var params = url.substr(url.indexOf("?") + 1).split('&');
var searchValue = params[0].split('=')[1];
//将要搜索的词语赋值到大标题中
document.getElementById('searchTitle').innerHTML = searchValue;

可以看到整个过程值的处理都是在前端完成的，并没有经过后端。这会涉及到一个很严重的问题：很多XSS防护都是在后端做的，将用户输入中的危险字符处理掉，但这种不经过后端的XSS会使得后端的防护失去作用。因此DOM型XSS需要在前端做防护，这便是将其单独分类出来的原因。
DOM型XSS的触发点通常在javscript代码中原生的innerHTML、outterHTML属性，jQuery中的html()函数，VueJs中的v-html等。

1.4 富文本XSS

富文本XSS相关的知识也是面试时经常会问到的问题之一。这里的『富文本』指的是用户通过官方提供的编辑器等途径，编写『所见即所得』的内容，做出格式与样式上的改变。这在论坛类网站中十分常见，富文本本质上是允许用户对html进行编辑，这天生就与XSS防护所对立——因为防护XSS时通常都是拼命阻止用户输入成为html的一部分。可想而知，在富文本的应用领域，存储型XSS会十分常见。这也使得富文本XSS的防御成为实现富文本功能时不得不重视的要素之一。
图
富文本XSS的防御主要依靠基于白名单的过滤，这也是目前业界最标准的方式。如在Java中，富文本XSS的过滤通常依靠jsoup库实现，jsoup是一个html解析库，具有解析html节点、自动补全等功能。其自带的clean方法可以去除白名单以外的所有标签，白名单则可以自行设定。当然，不仅仅是标签和属性，甚至连href、src属性值中的url链接的协议也可以限制（比如仅允许http/https协议，防止通过javascript/data协议进行XSS）。
由于对jsoup有过一定研究，这里可以多深入讲解一下jsoup.clean方法的原理。通常来说，除非白名单设定的有问题，误将危险标签加白，否则这种过滤是难以绕过的，这是因为jsoup.clean不是『剥离制』，而是『生成制』。即，他并不是将危险标签replace掉，而是解析DOM，检查解析后的每个标签、属性和url协议，如果在白名单内，则会将其加入一个新的html中，而加入过程并不是直接复制，而是直接通过标签名用其自己的标签生成函数来生成新标签。这样可以保证新html中都是白名单内的标签，然后将新的html作为结果返回，显而易见的，这种机制也会将不完整的html补全（因为新生成标签时会按照标准成对出现）。
扯远了，富文本XSS还有另一种防御方式，就是自定义一种标记方式，然后在后端将这种标记转化为html，比如bbcode。这样只有存在这种转化关系的标签可以正常生成，避免了黑客插入危险的html标签。不过遗憾的是，这种方式并不保险，在转化过程中，标记极有可能夹带html且被正常解析，如bbcode就曾爆发过XSS漏洞。

2.探测手段

漏洞的挖掘分为手动与自动，各有优劣。
手动挖掘追求的是深层次，比如一些很深的页面，需要复杂的交互逻辑才能抵达，并且有着不那么严格的防护机制，需要进行对抗方可挖到漏洞，缺点很明显，就是慢。
自动挖掘追求的是高效率，范围广，缺点也很明显，要么是几个payload打天下，太生硬，容易漏报；要么是一堆payload匡匡砸在人家的网站上，等着被封IP，并且一些深层次页面也无法触及。

2.1 XSS常出没之处

想要手动挖掘XSS就必然有着敏感的嗅觉，其实不单是XSS，了解漏洞常出现的地方是渗透测试人员的必修课。我的经验总结如下：

挖掘存储型XSS，凡是网站上可以输入并存留处，都可以尝试写入XSS Payload，并观察字符的变化情况，以此来确认哪些字符被转义，是否有继续对抗的必要。对于这里的判断，我会在后续绕过的章节中详述。
挖掘反射型XSS/DOM型XSS，可以关注地址栏中参数的值，是否有字符串，并且该字符串是否存在于本页html中。若有，则可将其替换为XSS Payload进行尝试。另外，凡是网站有提示类信息且样式模板相同，仅内容不同的，都可以寻找内容的输入源是否是来自于用户的，并针对输入源进行渗透。同样需要观察并判断是否进行对抗。
挖掘富文本XSS，除存储型XSS的挖掘方法外，由于其防御方式是基于白名单（甚至更不安全的黑名单）的，因此印证白名单是否存在危险标签也是测试的一部分。可以特别关注<svg>、<object>、<embed>、<标签名 x>等标签是否正确防御。