JSON, Ajax & Web 2.0

Now that Web 2.0 hype is at full tilt, much ado's being made over Ajax framework vulnerabilities and other new-fangled bugs. A prime example of this phenomenon is the spectacular Javascript hijacking vulnerability discovered by Fortify Software (login required). Every security bug like this deserves some ink, but too much focus on bugs may cause many security-minded developers to miss the big Web 2.0 security picture. Developers darn well need to be concerned about security bugs when they wield Ajax, but they also need to think very carefully about trust boundaries.

Javascript Hijacking
In mid-March, Fortify chief scientist Brian Chess announced the discovery of a bug termed Javascript hijacking. The bug was very similar to earlier vulnerabilities discovered by Jeremiah Grossman and Joe Walker. These bugs are all aimed at exploiting the fact that much Web 2.0 functionality is meant to be carried out by the client-side Web browser's Javascript engine.

The Fortify team found that all but one popular Ajax framework was susceptible to its attack, and that many custom Ajax applications not built on frameworks suffer from similar issues. In the attack, an unauthorized attacker can read confidential data from a vulnerable application because that information is transported by Javascript. Grossman's Gmail attack was an example of one such application. This attack allowed personal information from Gmail to be leaked to an attacker through Javascript.

Javascript Hijacking counts on a screw-up in the way that the Same Origin Policy is enforced by Web browsers. The problem allows Javascript from a malicious Website to examine data loaded from a vulnerable Website, even though the Websites are not the same. JSON (Javascript Object Notation) is the most popular format for sending around information in Javascript, and JSON arrays are directly vulnerable to this kind of attack.

Very cool mashups are often written using Ajax. In many cases, a mashup will invoke a callback function that is meant to be defined by other apps in the mashup. This is a security disaster and once again shows there is a fundamental tradeoff between cool new Web functionality and security. As the Fortify team says in its paper, "An application can be mashup-friendly or it can be secure, but it cannot be both."

Fortunately, there are short-term technical workarounds (kludges) to avoid vulnerabilities like Javascript hijacking. One approach involves tagging each request with a parameter that is hard to guess and difficult to forge. Session cookies can be used for this. Another approach is to prevent a malicious site from executing a response that has Javascript in it by requiring data modification before execution can happen (something that only a legitimate app should be able to do). Details on these approaches are spelled out in the Fortify paper. Note that these ideas really move the problem around but don't really solve it.

The Real Security Problem With Ajax
The real problem with Web 2.0 is much bigger than data exposure problems in Javascript might suggest. The real problem is a design issue involving trust boundaries and the way developers and architects think about the software they build.

Most people who build software think of their creation as a number of components (let's call these "boxes") that communicate through APIs in various ways (we'll call the communications lines "arrows"). In a traditional boxes-and-arrows software design, architects concern themselves with things like which box does what, which data flow where, and how the right kind of computations are performed in the right order. Most architects ponder a god's eye view of the system that treats the boxes as essentially equal parts of the system.

The problem with the Web 2.0 world is that many of the boxes run on untrustworthy machines. In fact, in the worst cases, these boxes run on intentionally malicious machines owned by an attacker. Attackers can then leverage the old chestnut "make the client invisible" attack pattern to break system security.

Put in more traditional security terms, part of the computation in a Web 2.0 design happens on the "untrusted" side of a critical trust boundary. If developers forget to account for the trust boundary in their design, they end up exposing critical data, essential computations, or other valuable information assets to attackers.

Ajax makes this kind of mistake easier than ever by treating a complete software system as a set of basically equivalent boxes and arrows with little focus on trust boundaries. Plus, trust boundaries expand when sensitive data and credentials are shoved around between the client and the server.

This kind of trust boundary problem is one that security engineers have wrestled with for years when dealing with distributed systems. In our new book, Exploiting Online Games, to be released in July, Greg Hoglund and I describe myriad security problems suffered by MMORPGs such as World of Warcraft and Second Life. A majority of these exploitable, monetizable problems involve mixed-up thinking about trust boundaries, which parts of a security-critical computation can be performed where, and what kinds of assumptions game developers make. I believe that the kinds of security problems suffered by massively distributed online games are a harbinger of the kinds of security problems we'll see in Web 2.0 software.

Until system designers gain a better understanding of trust boundaries and learn to avoid sending critical parts of their system directly to attackers, we'll end up with poor distributed system security. Be forewarned.

— Gary McGraw is CTO of Cigital Inc. Special to Dark Reading