Risk
6/7/2007
07:15 AM
50%
50%

JSON, Ajax & Web 2.0

Sounds like a classical reinvention, but this volatile trio opens the door to serious vulnerabilities

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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.