前端安全问题

前端安全问题
1、如何定义前端安全问题
如果我们把安全问题按照所发生的区域来进行分类的话
所有发生在后端服务器、应用、服务当中的安全问题就是后端安全问题
所有发生在浏览器、单页应用、web页面当中的安全问题就是前端安全问题
2、9大前端安全问题
XSS
iframe
点击劫持
错误的内容推断
不安全的第三方依赖包
HTTPS的坑
本地存储数据泄漏
缺失静态资源完整性校验
CSRF
3、XSS
3.1 介绍
跨站脚本攻击 - 本质在于：浏览器错误的将攻击者提供的用户输入数据当做JavaScript脚本给执行了
攻击者可以利用XSS漏洞来窃取包括用户身份信息在内的各种敏感信息、修改web页面以欺骗用户,甚至控制受害的浏览器或者和其它漏洞结合起来形成蠕虫攻击
3.2 分类
按照恶意输入的脚本是否在应用中存储划分为存储型XSS和反射型XSS
按照是否和服务器有交互,又可以划分为Server Side XSS和DOM based XSS
3.3 如何进行防御
最佳做法是对数据进行严格的输出编码,使得攻击者提供的数据不再被浏览器认为是脚本而被误执行
4、iframe
4.1 介绍
有的时候我们前端页面需要用到第三方提供的页面组件,通常会以iframe的方式引入
在带来页面丰富的同时也带来了安全隐患,默认情况下,第三方不受我们控制,他们可以在iframe中运行JavaScript脚本、Flash插件、弹出对话框,破坏用户体验
还有一些较大风险,域名可能因为过期被恶意攻击者抢注或者第三方被黑客攻破,iframe中的内容被替换掉,从而利用用户浏览器的安全漏洞下载安装木马
4.2 如何进行防御
添加iframe的属性sandbox,通过这个属性可以对iframe的行为进行各种限制,充分实现最小权限原则
理解：也就是说,如果你只是添加上这个属性而保持属性值为空,那么浏览器将会对iframe实施史上最严厉的调控限制,基本上来讲就是除了允许显示静态资源以外,其他什么都做不了.比如不准提交表单、不准弹窗、不准执行脚本等等,连Origin都会被强制重新分配一个唯一的值,换句话讲就是iframe中的页面访问它自己的服务器都会被算作跨域请求
4.3 sandbox参数

allow-forms：允许iframe中提交form表单

allow-popups：允许iframe中弹出新的窗口或者标签页（例如，window.open()，showModalDialog()，target=”_blank”等等）

allow-scripts：允许iframe中执行JavaScript

allow-same-origin：允许iframe中的网页开启同源策略
4.4 参考文档
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe
5、点击劫持
5.1 介绍
是一种需要用户高度参与的攻击

攻击步骤：

1)、攻击者精心构造一个诱导用户点击的内容，比如Web页面小游戏

2)、将我们的页面放入到iframe当中

3)、利用z-index等CSS样式将这个iframe叠加到小游戏的垂直方向的正上方

4)、把iframe设置为100%透明度

5)、受害者访问到这个页面后，肉眼看到的是一个小游戏，如果受到诱导进行了点击的话，实际上点击到的却是iframe中的我们的页面
5.2 危害
攻击利用了受害者的用户身份,在其不知情的情况下进行一些操作.如果只是迫使用户关注某个微博账号的话,看上去仿佛还可以承受,但是如果是删除某个重要文件记录,或者窃取敏感信息,那么造成的危害可就难以承受了
5.3 如何进行防御
有多种防御措施都可以防止页面遭到点击劫持攻击,例如Frame Breaking方案.一个推荐的防御方案是,使用X-Frame-Options：DENY这个HTTP Header来明确的告知浏览器,不要把当前HTTP响应中的内容在HTML Frame中显示出来
5.4 参考文档
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
6、错误的内容推断
6.1 介绍
某网站允许用户在评论里上传图片,攻击者在上传图片的时候,看似提交的是个图片文件,实则是个含有JavaScript的脚本文件.该文件逃过了文件类型校验(这涉及到了恶意文件上传这个常见安全问题,但是由于和前端相关度不高因此暂不详细介绍),在服务器里存储了下来.接下来,受害者在访问这段评论的时候,浏览器会去请求这个伪装成图片的JavaScript脚本,而此时如果浏览器错误的推断了这个响应的内容类型(MIME types),那么就会把这个图片文件当做JavaScript脚本执行,于是攻击也就成功了
6.2 关键
问题的关键就在于,后端服务器在返回的响应中设置的Content-Type Header仅仅只是给浏览器提供当前响应内容类型的建议,而浏览器有可能会自作主张的根据响应中的实际内容去推断内容的类型
6.3 如何进行防御
X-Content-Type-Options【通过设置X-Content-Type-Options这个HTTP Header明确禁止浏览器去推断响应类型】
6.4 参考文档
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
7、不安全的第三方依赖包
7.1 介绍
应用使用了如此多的第三方代码,不论应用自己的代码的安全性有多高,一旦这些来自第三方的代码有安全漏洞,那么对应用整体的安全性依然会造成严峻的挑战
7.2 如何进行防御
使用工具NSP、Snyk
8、HTTPS的坑
8.1 介绍
即使是服务器端开启了HTTPS,也还是存在安全隐患,黑客可以利用SSL Stripping这种攻击手段,强制让HTTPS降级回HTTP,从而继续进行中间人攻击
8.2 本质
本质在于浏览器发出去第一次请求就被攻击者拦截了下来并做了修改,根本不给浏览器和服务器进行HTTPS通信的机会.大致过程如下,用户在浏览器里输入URL的时候往往不是从https开始的,而是直接从域名开始输入,随后浏览器向服务器发起HTTP通信,然而由于攻击者的存在,它把服务器端返回的跳转到HTTPS页面的响应拦截了,并且代替客户端和服务器端进行后续的通信.由于这一切都是暗中进行的,所以使用前端应用的用户对此毫无察觉
8.3 如何进行防御
使用HSTS

// 通过下面这个HTTP Header以及一个预加载的清单，来告知浏览器在和网站进行通信的时候强制性的使用HTTPS，而不是通过明文的HTTP进行通信：

Strict-Transport-Security: max-age=; includeSubDomains; preload

// “强制性”表现为浏览器无论在何种情况下都直接向服务器端发起HTTPS请求，而不再像以往那样从HTTP跳转到HTTPS。另外，当遇到证书或者链接不安全的时候，则首先警告用户，并且不再让用户选择是否继续进行不安全的通信
9、本地存储数据泄露
在前端存储敏感、机密信息始终都是一件危险的事情,推荐的做法是尽可能不在前端存这些数据
10、缺乏静态资源完整性校验
10.1 介绍
出于性能考虑,前端应用通常会把一些静态资源存放到CDN（Content Delivery Networks）上面,例如Javascript脚本和Stylesheet文件.这么做可以显著提高前端应用的访问速度,但与此同时却也隐含了一个新的安全风险
如果攻击者劫持了CDN,或者对CDN中的资源进行了污染,那么我们的前端应用拿到的就是有问题的JS脚本或者Stylesheet文件,使得攻击者可以肆意篡改我们的前端页面,对用户实施攻击.这种攻击方式造成的效果和XSS跨站脚本攻击有些相似,不过不同点在于攻击者是从CDN开始实施的攻击,而传统的XSS攻击则是从有用户输入的地方开始下手的
10.2 如何进行防御
使用浏览器提供的SRI(Subresource Integrity)功能.顾名思义,这里的Subresource指的就是HTML页面中通过和元素所指定的资源文件

// 每个资源文件都可以有一个SRI值，就像下面这样。它由两部分组成，减号（-）左侧是生成SRI值用到的哈希算法名，右侧是经过Base64编码后的该资源文件的Hash值。