前端安全问题

参考：美团技术团队的前端安全系列

1、XSS攻击

定义
跨脚本攻击，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。

发生
恶意代码未经过过滤，与网站正常代码混淆，导致浏览器无法分辨脚本的可信度，导致恶意脚本被执行

危险
有意者会利用这些恶意脚本获取用户的敏感信息Cookie、SessionID等，进而危害数据安全

分类：

**存储区：恶意代存放的位置
**插入点：由谁取得恶意代码，并插入到网页上

存储型
1） 攻击者将恶意代码提交到目标网站的数据库
2） 用户打开目标网站时，网站服务端将恶意代码从数据库中取出，拼接在HTML中返回浏览器。
3） 恶意代码窃取用户数据并发送到攻击者网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
（常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信……）

反射型
1） 攻击者构造出特殊的URL，其中包含恶意代码
2） 用户打开带有恶意代码的URL时，网站服务将恶意代码从URL中取出，拼接在HTML返回给数据库。
3） 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
4） 恶意代码窃取用户数据并发送给攻击者网站，或者冒充用户行为，调用目标网站接口执行攻击者指定的操作。
（常见于通过URL传参的功能：网站搜索，跳转……）
（POST请求也可以触发反射型XSS，只不过条件比较苛刻，需要构造表单提交页面，并引导用户点击，所以比较少见）

DOM型
1） 攻击者构造出特殊的URL，其中包含恶意代码
2） 用户打开带有恶意代码的URL
3） 用户浏览器接收到响应后解析执行，前端js取出URL中的恶意代码执行
4） 恶意代码窃取用户数据并发送到攻击者网站，或者冒充用户行为，调用目标网站接口执行攻击者指定的操作。
（取出和执行恶意代码在浏览器端完成，属于前端js自身得的安全漏洞，而其他的都属于服务端的安全漏洞）

预防
XSS攻击的两大要素：
1、 攻击者提交恶意代码
2、 浏览器执行恶意代码

问题来了，针对第一种情况是否可以在用户输入的时候直接进行输入过滤呢？
答：不可，一旦攻击者绕过前端过滤，直接构造请求，就可以直接提交恶意代码。
如果换个思路，在后端写入数据库前，对输入进行过滤，然后把“”安全的“内容返回给前端是否可行？
具有很强的不确定性。
例：一个正常的用户输入了 5 < 7 这个内容，在写入数据库前，被转义，变成了 5 < 7
1） 用户输入的内容可能同时提供给前端和客户端，而一旦经过了 escapeHTML()，客户端显示的内容就变成了乱码（5 < 7）
2） 前端中，不同位置所需的编码不同
**当5 < 7作为HTML拼接页面时，可以正常显示

<div title="comment">5 &lt; 7</div>

当5 < 7返回ajax时，赋值给js变量时，前端得到的字符串就是转以后的字符。这个内容不能直接用于VUE等末班的展示，也不能直接用于内容长度计算，不能用于标题，alert等
（对于明确的输入类型，如数字、URL、电话号码、邮件等，进行输入过滤是必要的）

由上得出的我们要从第二个角度出发，防止浏览器执行恶意代码来防范XSS

**防止HTML中出现注入
**防止js执行时，执行恶意代码

预防存储型和反射型：

1） 改为纯前端，把代码合数据隔开 （前后端分离，但是还要注意DOM型的XSS漏洞，如onload事件和href中的javascript:xxx等）
2） 对HTML做充分转义（使用合适的转义库，对HTML模板各处插入点进行充分的转义—把 & < > " ’ / 转义掉）

预防DOM型：

1） 在使用 .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量使用 .textContent、.setAttribute() 等。
2） 如果用 Vue/React 技术栈，并且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 阶段避免 innerHTML、outerHTML 的 XSS 隐患。
3） DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等， 标签的 href 属性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免