安全测试===8大前端安全问题（下）

在《8大前端安全问题（上）》这篇文章里我们谈到了什么是前端安全问题，并且介绍了其中的4大典型安全问题，本篇文章将介绍剩下的4大前端安全问题，它们分别是：

• 防火防盗防猪队友：不安全的第三方依赖包

• 用了HTTPS也可能掉坑里

• 本地存储数据泄露

• 缺乏静态资源完整性校验

防火防盗防猪队友：不安全的第三方依赖包

现如今进行应用开发，就好比站在巨人的肩膀上写代码。据统计，一个应用有将近80%的代码其实是来自于第三方组件、依赖的类库等，而应用自身的代码其实只占了20%左右。无论是后端服务器应用还是前端应用开发，绝大多数时候我们都是在借助开发框架和各种类库进行快速开发。

这样做的好处显而易见，但是与此同时安全风险也在不断累积——应用使用了如此多的第三方代码，不论应用自己的代码的安全性有多高，一旦这些来自第三方的代码有安全漏洞，那么对应用整体的安全性依然会造成严峻的挑战。

（图片来自：http://t.cn/RlAQsZ0）

举个例子，jQuery就存在多个已知安全漏洞，例如jQuery issue 2432，使得应用存在被XSS攻击的可能。而Node.js也有一些已知的安全漏洞，比如CVE-2017-11499，可能导致前端应用受到DoS攻击。另外，对于前端应用而言，除使用到的前端开发框架之外，通常还会依赖不少Node组件包，它们可能也有安全漏洞。

手动检查这些第三方代码有没有安全问题是个苦差事，主要是因为应用依赖的这些组件数量众多，手工检查太耗时，好在有自动化的工具可以使用，比如NSP(Node Security Platform)，Snyk等等。

用了HTTPS也可能掉坑里

为了保护信息在传输过程中不被泄露，保证传输安全，使用TLS或者通俗的讲，使用HTTPS已经是当今的标准配置了。然而事情并没有这么简单，即使是服务器端开启了HTTPS，也还是存在安全隐患，黑客可以利用SSL Stripping这种攻击手段，强制让HTTPS降级回HTTP，从而继续进行中间人攻击。

问题的本质在于浏览器发出去第一次请求就被攻击者拦截了下来并做了修改，根本不给浏览器和服务器进行HTTPS通信的机会。大致过程如下，用户在浏览器里输入URL的时候往往不是从https://开始的，而是直接从域名开始输入，随后浏览器向服务器发起HTTP通信，然而由于攻击者的存在，它把服务器端返回的跳转到HTTPS页面的响应拦截了，并且代替客户端和服务器端进行后续的通信。由于这一切都是暗中进行的，所以使用前端应用的用户对此毫无察觉。

解决这个安全问题的办法是使用HSTS（HTTP Strict Transport Security），它通过下面这个HTTP Header以及一个预加载的清单，来告知浏览器在和网站进行通信的时候强制性的使用HTTPS，而不是通过明文的HTTP进行通信：

Strict-Transport-Security: max-age=<seconds>; includeSubDomains; preload

这里的“强制性”表现为浏览器无论在何种情况下都直接向服务器端发起HTTPS请求，而不再像以往那样从HTTP跳转到HTTPS。另外，当遇到证书或者链接不安全的时候，则首先警告用户，并且不再让用户选择是否继续进行不安全的通信。

（图片来自：http://t.cn/Rfj3Tku）

本地存储数据泄露

以前，对于一个Web应用而言，在前端通过Cookie存储少量用户信息就足够支撑应用的正常运行了。然而随着前后端分离，尤其是后端服务无状态化架构风格的兴起，伴随着SPA应用的大量出现，存储在前端也就是用户浏览器中的数据量也在逐渐增多。

前端应用是完全暴露在用户以及攻击者面前的，在前端存储任何敏感、机密的数据，都会面临泄露的风险，就算是在前端通过JS脚本对数据进行加密基本也无济于事。

举个例子来说明，假设你的前端应用想要支持离线模式，使得用户在离线情况下依然可以使用你的应用，这就意味着你需要在本地存储用户相关的一些数据，比如说电子邮箱地址、手机号、家庭住址等PII（Personal Identifiable Information）信息，或许还有历史账单、消费记录等数据。

尽管有浏览器的同源策略限制，但是如果前端应用有XSS漏洞，那么本地存储的所有数据就都可能被攻击者的JS脚本读取到。如果用户在公用电脑上使用了这个前端应用，那么当用户离开后，这些数据是否也被彻底清除了呢？前端对数据加密后再存储看上去是个防御办法，但其实仅仅提高了一点攻击门槛而已，因为加密所用到的密钥同样存储在前端，有耐心的攻击者依然可以攻破加密这道关卡。

所以，在前端存储敏感、机密信息始终都是一件危险的事情，推荐的做法是尽可能不在前端存这些数据。

缺乏静态资源完整性校验

出于性能考虑，前端应用通常会把一些静态资源存放到CDN（Content Delivery Networks）上面，例如Javascript脚本和Stylesheet文件。这么做可以显著提高前端应用的访问速度，但与此同时却也隐含了一个新的安全风险。

如果攻击者劫持了CDN，或者对CDN中的资源进行了污染，那么我们的前端应用拿到的就是有问题的JS脚本或者Stylesheet文件，使得攻击者可以肆意篡改我们的前端页面，对用户实施攻击。这种攻击方式造成的效果和XSS跨站脚本攻击有些相似，不过不同点在于攻击者是从CDN开始实施的攻击，而传统的XSS攻击则是从有用户输入的地方开始下手的。

防御这种攻击的办法是使用浏览器提供的SRI（Subresource Integrity）功能。顾名思义，这里的Subresource指的就是HTML页面中通过<script>和<link>元素所指定的资源文件。

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

<script src=“https://example.js” integrity=“sha384-eivAQsRgJIi2KsTdSnfoEGIRTo25NCAqjNJNZalV63WKX3Y51adIzLT4So1pk5tX”></script>

浏览器在处理这个script元素的时候，就会检查对应的JS脚本文件的完整性，看其是否和script元素中integrity属性指定的SRI值一致，如果不匹配，浏览器则会中止对这个JS脚本的处理。

小结

在上一篇和本篇文章中，我们为大家介绍了在开发前端应用的时候容易遇到的8大安全问题，它们是：

• 老生常谈的XSS

• 警惕iframe带来的风险

• 别被点击劫持了

• 错误的内容推断

• 防火防盗防猪队友：不安全的第三方依赖包

• 用了HTTPS也可能掉坑里

• 本地存储数据泄露

• 缺乏静态资源完整性校验

我们希望能通过对这些问题的介绍，引起前端开发小伙伴的注意，尽可能提前绕过这些安全问题的坑。