当我们说“前端安全问题”的时候，我们在说什么
“安全”是个很大的话题，各种安全问题的类型也是种类繁多。如果我们把安全问题按照所发生的区域来进行分类的话，那么所有发生在后端服务器、应用、服务当中的安全问题就是“后端安全问题”，所有发生在浏览器、单页面应用、Web页面当中的安全问题则算是“前端安全问题”。比如说，SQL注入漏洞发生在后端应用中，是后端安全问题，跨站脚本攻击(XSS)则是前端安全问题，因为它发生在用户的浏览器里。
除了从安全问题发生的区域来分类之外，也可以从另一个维度来判断：针对某个安全问题，团队中的哪个角色最适合来修复它?是后端开发还是前端开发?
总的来说，当我们下面在谈论“前端安全问题”的时候，我们说的是发生在浏览器、前端应用当中，或者通常由前端开发工程师来对其进行修复的安全问题。
8大前端安全问题
按照上面的分类办法，我们总结出了8大典型的前端安全问题，它们分别是：
- 老生常谈的XSS
- 警惕iframe带来的风险
- 别被点击劫持了
- 错误的内容推断
- 防火防盗防猪队友：不安全的第三方依赖包
- 用了HTTPS也可能掉坑里
- 本地存储数据泄露
- 缺失静态资源完整性校验
由于篇幅所限，本篇文章先给各位介绍前4个前端安全问题。
老生常谈的XSS
XSS是跨站脚本攻击(Cross-Site Scripting)的简称，它是个老油条了，在OWASP Web Application Top 10排行榜中长期霸榜，从未掉出过前三名。XSS这类安全问题发生的本质原因在于，浏览器错误的将攻击者提供的用户输入数据当做JavaScript脚本给执行了。
XSS有几种不同的分类办法，例如按照恶意输入的脚本是否在应用中存储，XSS被划分为“存储型XSS”和“反射型XSS”，如果按照是否和服务器有交互，又可以划分为“Server Side XSS”和“DOM based XSS”。
无论怎么分类，XSS漏洞始终是威胁用户的一个安全隐患。攻击者可以利用XSS漏洞来窃取包括用户身份信息在内的各种敏感信息、修改Web页面以欺骗用户，甚至控制受害者浏览器，或者和其他漏洞结合起来形成蠕虫攻击，等等。总之，关于XSS漏洞的利用，只有想不到没有做不到。
如何防御
防御XSS最佳的做法就是对数据进行严格的输出编码，使得攻击者提供的数据不再被浏览器认为是脚本而被误执行。例如<script>在进行HTML编码后变成了<script>，而这段数据就会被浏览器认为只是一段普通的字符串，而不会被当做脚本执行了。
编码也不是件容易的事情，需要根据输出数据所在的上下文来进行相应的编码。例如刚才的例子，由于数据将被放置于HTML元素中，因此进行的是HTML编码，而如果数据将被放置于URL中，则需要进行URL编码，将其变为%3Cscript%3E。此外，还有JavaScript编码、CSS编码、HTML属性编码、JSON编码等等。好在现如今的前端开发框架基本上都默认提供了前端输出编码，这大大减轻了前端开发小伙伴们的工作负担。
其他的防御措施，例如设置CSP HTTP Header、输入验证、开启浏览器XSS防御等等都是可选项，原因在于这些措施都存在被绕过的可能，并不能完全保证能防御XSS攻击。不过它们和输出编码却可以共同协作实施纵深防御策略。
你可以查阅OWASP XSS Prevention Cheat Sheet，里面有关于XSS及其防御措施的详细说明。
警惕iframe带来的风险
有些时候我们的前端页面需要用到第三方提供的页面组件，通常会以iframe的方式引入。典型的例子是使用iframe在页面上添加第三方提供的广告、天气预报、社交分享插件等等。
iframe在给我们的页面带来更多丰富的内容和能力的同时，也带来了不少的安全隐患。因为iframe中的内容是由第三方来提供的，默认情况下他们不受我们的控制，他们可以在iframe中运行JavaScirpt脚本、Flash插件、弹出对话框等等，这可能会破坏前端用户体验。
如果说iframe只是有可能会给用户体验带来影响，看似风险不大，那么如果iframe中的域名因为过期而被恶意攻击者抢注，或者第三方被黑客攻破，iframe中的内容被替换掉了，从而利用用户浏览器中的安全漏洞下载安装木马、恶意勒索软件等等，这问题可就大了。
如何防御
还好在HTML5中，iframe有了一个叫做sandbox的安全属性，通过它可以对iframe的行为进行各种限制，充分实现“最小权限“原则。使用sandbox的最简单的方式就是只在iframe元素中添加上这个关键词就好，就像下面这样：
- <iframe sandbox src="..."> ... </iframe>
sandbox还忠实的实现了“Secure By Default”原则，也就是说，如果你只是添加上这个属性而保持属性值为空，那么浏览器将会对iframe实施史上最严厉的调控限制，基本上来讲就是除了允许显示静态资源以外，其他什么都做不了。比如不准提交表单、不准弹窗、不准执行脚本等等，连Origin都会被强制重新分配一个唯一的值，换句话讲就是iframe中的页面访问它自己的服务器都会被算作跨域请求。
另外，sandbox也提供了丰富的配置参数，我们可以进行较为细粒度的控制。一些典型的参数如下：
- allow-forms：允许iframe中提交form表单
- allow-popups：允许iframe中弹出新的窗口或者标签页(例如，window.open()，showModalDialog()，target=”_blank”等等)
- allow-scripts：允许iframe中执行JavaScript
- allow-same-origin：允许iframe中的网页开启同源策略
更多详细的资料，可以参考iframe中关于sandbox的介绍。
别被点击劫持了
有个词叫做防不胜防，我们在通过iframe使用别人提供的内容时，我们自己的页面也可能正在被不法分子放到他们精心构造的iframe或者frame当中，进行点击劫持攻击。
这是一种欺骗性比较强，同时也需要用户高度参与才能完成的一种攻击。通常的攻击步骤是这样的：
- 攻击者精心构造一个诱导用户点击的内容，比如Web页面小游戏;
- 将我们的页面放入到iframe当中;
- 利用z-index等CSS样式将这个iframe叠加到小游戏的垂直方向的正上方;
- 把iframe设置为100%透明度;
- 受害者访问到这个页面后，肉眼看到的是一个小游戏，如果受到诱导进行了点击的话，实际上点击到的却是iframe中的我们的页面。
点击劫持的危害在于，攻击利用了受害者的用户身份，在其不知情的情况下进行一些操作。如果只是迫使用户关注某个微博账号的话，看上去仿佛还可以承受，但是如果是删除某个重要文件记录，或者窃取敏感信息，那么造成的危害可就难以承受了。
如何防御
有多种防御措施都可以防止页面遭到点击劫持攻击，例如Frame Breaking方案。一个推荐的防御方案是，使用X-Frame-Options：DENY这个HTTP Header来明确的告知浏览器，不要把当前HTTP响应中的内容在HTML Frame中显示出来。
关于点击劫持更多的细节，可以查阅OWASP Clickjacking Defense Cheat Sheet。
错误的内容推断
想象这样一个攻击场景：某网站允许用户在评论里上传图片，攻击者在上传图片的时候，看似提交的是个图片文件，实则是个含有JavaScript的脚本文件。该文件逃过了文件类型校验(这涉及到了恶意文件上传这个常见安全问题，但是由于和前端相关度不高因此暂不详细介绍)，在服务器里存储了下来。接下来，受害者在访问这段评论的时候，浏览器会去请求这个伪装成图片的JavaScript脚本，而此时如果浏览器错误的推断了这个响应的内容类型(MIME types)，那么就会把这个图片文件当做JavaScript脚本执行，于是攻击也就成功了。
问题的关键就在于，后端服务器在返回的响应中设置的Content-Type Header仅仅只是给浏览器提供当前响应内容类型的建议，而浏览器有可能会自作主张的根据响应中的实际内容去推断内容的类型。
在上面的例子中，后端通过Content-Type Header建议浏览器按照图片来渲染这次的HTTP响应，但是浏览器发现响应中其实是JavaScript，于是就擅自做主把这段响应当做JS脚本来解释执行，安全问题也就产生了。
如何防御
浏览器根据响应内容来推断其类型，本来这是个很“智能”的功能，是浏览器强大的容错能力的体现，但是却会带来安全风险。要避免出现这样的安全问题，办法就是通过设置X-Content-Type-Options这个HTTP Header明确禁止浏览器去推断响应类型。
同样是上面的攻击场景，后端服务器返回的Content-Type建议浏览器按照图片进行内容渲染，浏览器发现有X-Content-Type-OptionsHTTP Header的存在，并且其参数值是nosniff，因此不会再去推断内容类型，而是强制按照图片进行渲染，那么因为实际上这是一段JS脚本而非真实的图片，因此这段脚本就会被浏览器当作是一个已经损坏或者格式不正确的图片来处理，而不是当作JS脚本来处理，从而最终防止了安全问题的发生。
小结
本文对前端安全问题进行了一次梳理，介绍了其中4个典型的前端安全问题，包括它们发生的原因以及防御办法。在下篇文章中，我们将介绍其他的几个前端安全问题，敬请期待。
【本文是51CTO专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】
