如何保护EmberJS或任何Javascript MVC框架？

Question

我期待着开始Ember.js在一个真实的项目中使用,但作为一个来自Java背景的人,我总是关心安全性.

当我对我的Java开发人员说,我开始使用JavaScript MVC时,他们开始说它不够安全,因为JavaScript完全是关于客户端的,总是有一种方法可以破解你的JavaScript代码,并知道你的后门服务和API.

那么有什么好的做法可以帮助防止这种攻击,或者至少试图降低它的效率？

Answer 1

总有一种方法来破解你的javascript代码,并了解你的服务和API的后门.

JavaScript为已经暴露给Web的服务和API提供了一些新问题.您的服务器/服务不应盲目地信任来自Web的请求,因此使用javascript不会改变您的安全状态,但它可以让人们认为他们控制用户代理,从而使人们陷入虚假的安全感.

客户端/服务器安全性的基本规则仍然是相同的:不信任用户代理 ; 将服务器和客户端放在信任边界的不同侧.

信任边界可以被认为是通过程序绘制的线.在该行的一侧,数据是不可信的.在该行的另一侧,数据被认为是值得信赖的.验证逻辑的目的是允许数据安全地跨越信任边界 - 从不受信任转移到受信任.

验证服务器从客户端收到的所有内容,并且由于XSS漏洞很常见并允许客户端访问发送到客户端的信息,因此尽可能少地向客户端发送敏感信息.

当您确实需要将数据从服务器往返到客户端并返回时,您可以使用各种技术.

1. 对数据进行加密签名,以便服务器可以验证它是否未被篡改.
2. 将数据存储在边表中,仅发送不透明的,不可取的标识符.

当您确实需要将敏感数据发送到客户端时,您还有各种策略:

1. 将数据存储在仅HTTP的cookie中,这些cookie附加到请求但JavaScript无法读取
2. 将您的客户划分为不同来源的iframe,并将敏感信息隔离在iframe中,该iframe经过特别仔细审核,并且具有最少的多余功能.

签名

签名解决了验证从不受信任的来源收到的数据是您之前验证过的数据的问题.它不能解决窃听问题(因为您需要加密)或决定不返回数据的客户端或决定用相同密钥替换的不同数据的替代问题.

Django文档很好地解释了"传递"数据的加密签名,该文档还概述了如何使用它们的API.

Web应用程序安全性的黄金法则是永远不要信任来自不受信任来源的数据.有时,通过不受信任的介质传递数据会很有用.在知道将检测到任何篡改的情况下,密码签名的值可以通过不受信任的信道安全传递.

Django既提供用于签名值的低级API,也提供用于设置和读取签名cookie的高级API,这是签名Web应用程序的最常见用途之一.

您可能还会发现签名对以下内容有用:

1. 生成"恢复我的帐户"URL,以便发送给丢失密码的用户.
2. 确保存储在隐藏表单字段中的数据未被篡改.
3. 生成一次性秘密URL以允许临时访问受保护资源,例如用户已付费的可下载文件.

不透明的标识符

不透明的标识符和边表解决了与签名相同的问题,但需要服务器端存储,并要求存储数据的计算机可以访问与接收标识符的计算机相同的数据库.

通过查看此图表,可以很容易地理解具有不透明,不可取的标识符的边表

     Server DB Table

+--------------------+---------------------+
| Opaque Primary Key | Sensitive Info      |
+--------------------+---------------------+
| ZXu4288a37b29AA084 | The king is a fink! |
| ...                | ...                 |
+--------------------+---------------------+

您使用随机或安全的伪随机数生成器生成密钥,并将密钥发送到客户端.

如果客户端有密钥,他们所知道的只是他们拥有一个随机数,并且可能与他们从您那里收到的其他随机数相同,但无法从中获取内容.

如果他们篡改(发回不同的密钥),那么这将不在您的表中(具有非常高的可能性),因此您将检测到篡改.

如果您向同一个行为不端的客户发送多个密钥,他们当然可以用另一个替换另一个.

仅限HTTP的cookie

当您发送每个用户代理的秘密时,您不希望它意外泄漏给其他用户代理,那么仅HTTP的cookie是一个不错的选择.

如果HTTP响应头中包含HttpOnly标志(可选),则无法通过客户端脚本访问cookie(如果浏览器支持此标志,则再次访问).因此,即使存在跨站点脚本(XSS)缺陷,并且用户意外访问利用此漏洞的链接,浏览器(主要是Internet Explorer)也不会向第三方透露cookie.

现代浏览器广泛支持HttpOnly cookie.

隔离的iframe

将应用程序划分为多个iframe是允许富客户端操作敏感数据同时将意外泄漏风险降至最低的最佳方法.

基本思想是在较大的程序中安装小程序(安全内核),以便比整个程序更仔细地审查您的安全敏感代码.这与qmail合作的可疑进程的工作方式相同.

安全模式:区划[VM02]

问题

系统的一个部分中的安全性故障允许系统的另一部分被利用.

解

将每个部分放在一个单独的安全域中.即使一个部件的安全性受到损害,其他部件仍然是安全的.

"HTML5方式的跨框架通信"解释了iframe如何进行通信.由于它们位于不同的域中,因此安全敏感的iframe知道其他域上的代码只能通过这些窄通道与其通信.

HTML允许您在元素中将一个网页嵌入到另一个网页中.它们基本上是分开的.容器网站只允许与其Web服务器通信,并且只允许iframe与其原始服务器通信.此外,由于它们具有不同的来源,浏览器不允许两个帧之间的任何接触.这包括函数调用和变量访问.

但是如果你想在两个独立的窗口之间获取一些数据呢？例如,转换为字符串时,zwibbler文档的长度可能是兆字节.我希望包含的网页能够在需要时获得该字符串的副本,因此可以保存它.此外,它应该能够访问用户生成的已保存的PDF,PNG或SVG图像.HTML5提供了一种在同一窗口的不同帧之间进行通信的受限方式,称为window.postMessage().

现在,安全敏感帧可以使用标准验证技术来审查来自(可能受到危害的)不太敏感的帧的数据.

您可以让一大群程序员高效地工作以生成出色的应用程序,而一个小得多的小组则确保敏感数据得到妥善处理.

一些缺点:

1. 启动应用程序更复杂,因为没有单个"加载"事件.
2. iframe通信需要传递需要解析的字符串,因此安全敏感帧仍然需要使用安全解析方法(没有eval来自postMessage的字符串.)
3. iframe是矩形的,因此如果安全敏感框架需要呈现UI,那么它可能不容易整齐地适应较大的应用程序的UI.