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

Question

我期待着开始使用 Ember.js在现实生活中的项目中，但作为来自 Java 背景的人，我总是关心安全性。

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

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

Answer 1

There is always a way to hack around your javascript code, and know backdoors to your services and APIs.

JavaScript 为已经暴露在网络上的服务和 API 带来了一些新问题。您的服务器/服务不应盲目信任来自 Web 的请求，因此使用 javascript 不会改变您的安全状况，但它会使人们认为他们控制了用户代理，从而使他们产生错误的安全感。

客户端/服务器安全的基本规则还是一样的: 不要相信用户代理 ;将服务器和客户端放在 trust boundary 的不同侧.

A trust boundary can be thought of as line drawn through a program. On one side of the line, data is untrusted. On the other side of the line, data is assumed to be trustworthy. The purpose of validation logic is to allow data to safely cross the trust boundary--to move from untrusted to trusted.

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

当您确实需要在服务器和客户端之间来回传输数据时，您可以使用各种技术。

对数据进行加密签名，以便服务器可以验证它没有被篡改。

将数据存储在一个边表中，并且只发送一个不透明的、不可猜测的标识符。

当您确实需要向客户端发送敏感数据时，您还有多种策略:

将数据存储在 HTTP-only cookie 中，这些 cookie 附加到请求但 JavaScript 无法读取

将您的客户端划分为不同来源的 iframe，并将敏感信息隔离在 iframe 中，该 iframe 经特别仔细审查，并且具有最少的多余功能。

签约

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

Django 很好地解释了“传递”数据的加密签名。还概述了如何使用其 API 的文档。

The golden rule of Web application security is to never trust data from untrusted sources. Sometimes it can be useful to pass data through an untrusted medium. Cryptographically signed values can be passed through an untrusted channel safe in the knowledge that any tampering will be detected.

Django provides both a low-level API for signing values and a high-level API for setting and reading signed cookies, one of the most common uses of signing in Web applications.

You may also find signing useful for the following:

1. Generating “recover my account” URLs for sending to users who have lost their password.
2. Ensuring data stored in hidden form fields has not been tampered with.
3. Generating one-time secret URLs for allowing temporary access to a protected resource, for example a downloadable file that a user has paid for.

不透明标识符

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

通过查看此图可以轻松理解带有不透明、不可猜测的标识符的边表

     Server DB Table

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

您使用 random or secure pseudo-random number generator 生成 key 并将 key 发送给客户端。

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

如果他们篡改(发回不同的 key )，那么它就不会在您的表中(很有可能)，因此您将检测到篡改。

如果您向同一个行为不端的客户端发送多个 key ，他们当然可以用一个替换另一个。

HTTP-only cookies

当您发送每个用户代理的 secret ，并且不希望它意外泄露给其他用户代理时，仅 HTTP cookie 是一个不错的选择。

If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.

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

隔离的 iframe

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

基本思想是将小程序(安全内核)放在一个更大的程序中，这样您的安全敏感代码可以比整个程序更仔细地审查。这与 qmail's cooperating suspicious processes 的方式相同工作。

Security Pattern: Compartmentalization [VM02]

Problem

A security failure in one part of a system allows another part of the system to be exploited.

Solution

Put each part in a separate security domain. Even when the security of one part is compromised, the other parts remain secure.

"Cross-frame communication the HTML5 way"解释了 iframe 如何进行通信。由于它们位于不同的域中，安全敏感的 iframe 知道其他域上的代码只能通过这些狭窄的 channel 与其通信。

HTML allows you to embed one web page inside another, in the element. They remain essentially separated. The container web site is only allowed to talk to its web server, and the iframe is only allowed to talk to its originating server. Furthermore, because they have different origins, the browser disallows any contact between the two frames. That includes function calls, and variable accesses.

But what if you want to get some data in between the two separate windows? For example, a zwibbler document might be a megabyte long when converted to a string. I want the containing web page to be able to get a copy of that string when it wants, so it can save it. Also, it should be able to access the saved PDF, PNG, or SVG image that the user produces. HTML5 provides a restricted way to communicate between different frames of the same window, called window.postMessage().

现在，安全敏感框架可以使用标准验证技术来审查来自(可能受到损害的)不太敏感的框架的数据。

您可以让一大群程序员高效地工作以生成出色的应用程序，而一小群程序员则致力于确保正确处理敏感数据。

一些缺点:

启动应用程序更加复杂，因为没有单一的“加载”事件。

iframe 通信需要传递需要解析的字符串，所以安全敏感的帧仍然需要使用安全解析方法(没有来自 postMessage 的字符串的 eval。)

iframe 是矩形的，所以如果安全敏感的框架需要呈现 UI，那么它可能不容易整齐地融入更大的应用程序的 UI。