How to secure EmberJS or any Javascript MVC framework?

Question

I'm looking forward to start using Ember.js in a real life project, but as someone coming from a Java background, I always care about Security.

And when I say to my fellow Java developers, I start using a JavaScript MVC, they start saying it's not secure enough, as JavaScript is all about client-side there is always a way to hack around your JavaScript code, and know backdoors to your services and APIs.

So is there any good practice that can help prevent this kind of attacks, or at least trying to make it less effective?

Answer 1

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

JavaScript presents few new problems for services and APIs that are already exposed to the web. Your server/service shouldn't blindly trust requests from the web, so using javascript doesn't alter your security posture, but it can lull people into a false sense of security by making them think they control the user-agent.

The basic rule of client/server security is still the same: don't trust the user-agent ; place the server and the client on different sides of a 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.

Validate everything that the server receives from the client, and, because XSS vulnerabilities are common and allow clients to access information sent to the client, send as little sensitive information to the client as possible.

When you do need to round-trip data from the server to the client and back, you can use a variety of techiniques.

1. Cryptographically sign the data so that the server can verify that it was not tampered with.
2. Store the data in a side-table and only send an opaque, unguessable identifier.

When you do need to send sensitive data to the client, you also have a variety of strategies:

1. Store the data in HTTP-only cookies which get attached to requests but which are not readable by JavaScript
2. Divide your client into iframes on separate origins, and sequester the sensitive information in an iframe that is especially carefully reviewed, and has minimal excess functionality.

---

Signing

Signing solves the problem of verifying that data you received from an untrusted source is data that you previously verified. It does not solve the problem of eavesdropping (for that you need encryption) or of a client that decides not to return data or that decides to substituting different data signed with the same key.

Cryptographic signing of "pass-through" data is explained well by the Django docs which also outline how their APIs can be used.

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.

---

Opaque Identifiers

Opaque identifiers and side tables solve the same problem as signing, but require server-side storage, and requires that the machine that stored the data have access to the same DB as the machine that receives the identifier back.

Side tables with opaque, unguessable, identifiers can be easily understood by looking at this diagram

     Server DB Table

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

You generate the key using a random or secure pseudo-random number generator and send the key to the client.

If the client has the key, all they know is that they possess a random number, and possibly that it is the same as some other random number they received from you, but cannot derive content from it.

If they tamper (send back a different key) then that will not be in your table (with very high likelihood) so you will have detected tampering.

If you send multiple keys to the same misbehaving client, they can of course substitute one for the other.

---

HTTP-only cookies

When you're sending a per-user-agent secret that you don't want it to accidentally leak to other user-agents, then HTTP-only cookies are a good option.

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 cookies are widely supported on modern browsers.

---

Sequestered iframes

Dividing your application into multiple iframes is the best current way to allow your rich client to manipulate sensitive data while minimizing the risk of accidental leakage.

The basic idea is to have small programs (secure kernels) within a larger program so that your security sensitive code can be more carefully reviewed than the program as a whole. This is the same way that qmail's cooperating suspicious processes worked.

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" explains how iframes can communicate. Since they're on different domains, the security sensitive iframe knows that code on other domains can only communicate with it through these narrow channels.

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().

Now the security-sensitive frame can use standard verification techniques to vet data from the (possibly-compromised) less-sensitive frame.

You can have a large group of programmers working efficiently at producing a great application, while a much smaller group works on making sure that the sensitive data is properly handled.

Some downsides:

1. Starting up an application is more complex because there is no single "load" event.
2. Iframe communication requires passing strings that need to be parsed, so the security-sensitive frame still needs to use secure parsing methods (no eval of the string from postMessage.)
3. Iframes are rectangular, so if the security-sensitive frame needs to present a UI, then it might not easily fit neatly into the larger application's UI.