前言
平时很少关注安全这块的技术，曾经也买过一本《Web前端黑客技术揭秘》但至今还没翻过，尴尬。今天的早读文章由腾讯优测@小吉带来的分享。
正文从这开始~
最近深入了解了一下XSS攻击。以前总浮浅的认为XSS防御仅仅只是输入过滤可能造成的XSS而已。然而这池子水深的很呐。
XSS的类型
总体来说，XSS分三类，存储型XSS、反射型XSS、DOM-XSS。
存储型XSS
数据库中存有的存在XSS攻击的数据，返回给客户端。若数据未经过任何转义。被浏览器渲染。就可能导致XSS攻击；
反射型XSS
将用户输入的存在XSS攻击的数据，发送给后台，后台并未对数据进行存储，也未经过任何过滤，直接返回给客户端。被浏览器渲染。就可能导致XSS攻击；
DOM-XSS
纯粹发生在客户端的XSS攻击，比如：http://www.some.site/page.html?default=French
页面代码：
该XSS攻击实现条件：
用户点击了如下连接：
http://www.some.site/page.html?default=
后台对URL参数未做任何过滤处理，返回给客户端，前端直接从url上获取参数。
打开网址的浏览器是低版本浏览器，常见ie8以下
满足以上三者，就会导致URL上的js代码执行:alert(document.cookie)，但是攻击者可以利用这个，做你无法想象的事情。在现代浏览器中，已经做了xss过滤，一旦检测到xss,会提示报错如下:
以上便是学术上的划分的XSS攻击类型，2、3类型其实都是反射型的攻击。了解了这些，意识到XSS攻击无处不在啊。那么如何对XSS进行防御？从输入到输出都需要过滤、转义。
XSS防御—输入输出的过滤和数据转义
输入
客户端求情参数：包括用户输入，url参数、post参数。
在产品形态上，针对不同输入类型，对输入做变量类型限制。
如，http://xss.qq.com?default=12，Default值强制限制为整形。
我们的后台是node，使用joi对于输入做类型限制：
字符串类型的数据，需要针对<、>、/、’、”、&五个字符进行实体化转义。
输出
即使在客户端对用户的输入做了过滤、转义，攻击者一样可能，通过截包，转发等手段，修改你的请求包体。最终还是要在数据输出的时候做数据转义。
好啦，到数据转义啦，不就是对<>,'&'这些字符做实体化转义吗？如果你认为这么简单，NO NO NO…因为浏览器解析中html和js编码不一样，以及上下文场景多样，所以对于后台输出的变量，不同的上下文中渲染后端变量，转码不一样。
下面的HTML片段显示了如何安全地在多种不同的上下文中渲染不可信数据。
情况一
数据类型：String
上下文：HTML Body
示例代码：UNTRUSTED DATA
防御措施：HTML Entity编码
情况二
数据类型：String
上下文：安全HTML变量
示例代码：
防御措施
1. HTML Attribute编码
2. 只把不可信数据放在安全白名单内的变量上（白名单在下文列出）
3. 严格地校验不安全变量，如background、id和name
情况三
数据类型：String
上下文：GET参数
示例代码：clickme
防御措施：URL编码
情况四
数据类型：String
上下文：使用在src或href变量上的不可信URLs
示例代码：
防御措施：
1. 对输入进行规范化
2. URL校验
3. URL安全性认证
4. 只允许使用http和https协议（避免使用JavaScript协议去打开一个新窗口）
5. HTML Attribute编码
情况五
数据类型：String
上下文：CSS值
示例代码：
防御措施：
1. 使用CSS编码
2. 使用CSS Hex编码
3. 良好的CSS设计
情况六
数据类型：String
上下文：JavaScript变量
示例代码：
防御措施：
1. 确保所有变量值都被引号括起来
2. 使用JavaScript Hex编码
3. 使用JavaScript Unicode编码
4. 避免使用“反斜杠转译”（\'、\'或者\）
情况七
数据类型：HTML
上下文：HTML Body
示例代码：
防御措施：
[HTML校验 (JSoup, AntiSamy, HTML Sanitizer)]
(https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way)
情况八
数据类型：String
上下文：DOM XSS
示例代码：
联系客服
