安全测试===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也可能掉坑里

• 本地存储数据泄露

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

咱们但愿能经过对这些问题的介绍，引发前端开发小伙伴的注意，尽量提早绕过这些安全问题的坑。