1.有哪些可能引起前端安全的的问题?
- 跨站脚本 (Cross-Site Scripting, XSS): ⼀种代码注⼊⽅式, 为了与 CSS 区分所以被称作 XSS. 早期常⻅于⽹络论坛,起因是⽹站没有对⽤户的输⼊进⾏严格的限制, 使得攻击者可以将脚本上传到帖⼦让其他⼈浏览到有恶意脚本的⻚⾯, 其注⼊⽅式很简单包括但不限于 JavaScript / VBScript / CSS / Flash 等
- iframe的滥⽤: iframe中的内容是由第三⽅来提供的，默认情况下他们不受我们的控制，他们可以在iframe中运⾏JavaScirpt脚本、Flash插件、弹出对话框等等，这可能会破坏前端⽤户体验
- 跨站点请求伪造（Cross-Site Request Forgeries，CSRF）: 指攻击者通过设置好的陷阱，强制对已完成认证的⽤户进⾏⾮预期的个⼈信息或设定信息等某些状态更新，属于被动攻击
- 恶意第三⽅库: ⽆论是后端服务器应⽤还是前端应⽤开发，绝⼤多数时候我们都是在借助开发框架和各种类库进⾏快速开发,⼀旦第三⽅库被植⼊恶意代码很容易引起安全问题,⽐如event-stream的恶意代码事件,2018年11⽉21⽇，名为 FallingSnow的⽤户在知名JavaScript应⽤库event-stream在github Issuse中发布了针对植⼊的恶意代码的疑问，表示event-stream中存在⽤于窃取⽤户数字钱包的恶意代码
2.XSS分为哪⼏类?
根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种。
- 存储区：恶意代码存放的位置。
- 插⼊点：由谁取得恶意代码，并插⼊到⽹⻚上。
3.存储型 XSS 的攻击步骤
- 攻击者将恶意代码提交到⽬标⽹站的数据库中。
- ⽤户打开⽬标⽹站时，⽹站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
- ⽤户浏览器接收到响应后解析执⾏，混在其中的恶意代码也被执⾏。
- 恶意代码窃取⽤户数据并发送到攻击者的⽹站，或者冒充⽤户的⾏为，调⽤⽬标⽹站接⼝执⾏攻击者指定的操作。
- 这种攻击常⻅于带有⽤户保存数据的⽹站功能，如论坛发帖、商品评论、⽤户私信等。
4.反射型 XSS 的攻击步骤：
- 攻击者构造出特殊的 URL，其中包含恶意代码。
- ⽤户打开带有恶意代码的 URL 时，⽹站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
- ⽤户浏览器接收到响应后解析执⾏，混在其中的恶意代码也被执⾏。
- 恶意代码窃取⽤户数据并发送到攻击者的⽹站，或者冒充⽤户的⾏为，调⽤⽬标⽹站接⼝执⾏攻击者指定的操作。
反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库⾥，反射型 XSS 的恶意代码存在 URL ⾥。
反射型 XSS 漏洞常⻅于通过 URL 传递参数的功能，如⽹站搜索、跳转等。
5.DOM 型 XSS 的攻击步骤：
- 攻击者构造出特殊的 URL，其中包含恶意代码。
- ⽤户打开带有恶意代码的 URL。
- ⽤户浏览器接收到响应后解析执⾏，前端 JavaScript 取出 URL 中的恶意代码并执⾏。
- 恶意代码窃取⽤户数据并发送到攻击者的⽹站，或者冒充⽤户的⾏为，调⽤⽬标⽹站接⼝执⾏攻击者指定的操作。
DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执⾏恶意代码由浏览器端完成，属于前端
JavaScript ⾃身的安全漏洞，⽽其他两种 XSS 都属于服务端的安全漏洞。
6.如何预防XSS?
XSS 攻击有两⼤要素：
1. 攻击者提交恶意代码。
2. 浏览器执⾏恶意代码。
针对第⼀个要素：我们是否能够在⽤户输⼊的过程，过滤掉⽤户输⼊的恶意代码呢？
输⼊过滤
- 防⽌ HTML 中出现注⼊
- 防⽌ JavaScript 执⾏时，执⾏恶意代码
7.预防存储型和反射型 XSS 攻击
存储型和反射型 XSS 都是在服务端取出恶意代码后，插⼊到响应 HTML ⾥的，攻击者刻意编写的“数据”被内嵌到“代码”中，被浏览器所执⾏。
预防这两种漏洞，有两种常⻅做法：
- 改成纯前端渲染，把代码和数据分隔开。
- 对 HTML 做充分转义。
纯前端渲染的过程：
1. 浏览器先加载⼀个静态 HTML，此 HTML 中不包含任何跟业务相关的数据。
2. 然后浏览器执⾏ HTML 中的 JavaScript。
3. JavaScript 通过 Ajax 加载业务数据，调⽤ DOM API 更新到⻚⾯上
在纯前端渲染中，我们会明确的告诉浏览器：下⾯要设置的内容是⽂本（ .innerText ），还是属性
（ .setAttribute ），还是样式（ .style ）等等。浏览器不会被轻易的被欺骗，执⾏预期外的代码了。
但纯前端渲染还需注意避免 DOM 型 XSS 漏洞（例如 onload 事件和 href 中的 javascript:xxx 等，请参考下⽂”预防 DOM 型 XSS 攻击“部分）。
在很多内部、管理系统中，采⽤纯前端渲染是⾮常合适的。但对于性能要求⾼，或有 SEO 需求的⻚⾯，我们仍然要⾯对拼接 HTML 的问题。
转义 HTML ：
如果拼接 HTML 是必要的，就需要采⽤合适的转义库，对 HTML 模板各处插⼊点进⾏充分的转义。
常⽤的模板引擎，如 doT.js、ejs、FreeMarker 等，对于 HTML 转义通常只有⼀个规则，就是把 & < > " ' / 这⼏个
字符转义掉，确实能起到⼀定的 XSS 防护作⽤，但并不完善：
|XSS 安全漏洞|简单转义是否有防护作⽤| |-|-| |HTML 标签⽂字内容|有| |HTML 属性值|有| |CSS 内联样式|⽆| |内联
JavaScript|⽆| |内联 JSON|⽆| |跳转链接|⽆|
所以要完善 XSS 防护措施，我们要使⽤更完善更细致的转义策略。
