Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Navigating the Asia-Pacific Threat Landscape: Experts Dive In
Kelly Sheridan, Staff Editor, Dark Reading,  9/25/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-26120
PUBLISHED: 2020-09-27
XSS exists in the MobileFrontend extension for MediaWiki before 1.34.4 because section.line is mishandled during regex section line replacement from PageGateway. Using crafted HTML, an attacker can elicit an XSS attack via jQuery's parseHTML method, which can cause image callbacks to fire even witho...
CVE-2020-26121
PUBLISHED: 2020-09-27
An issue was discovered in the FileImporter extension for MediaWiki before 1.34.4. An attacker can import a file even when the target page is protected against "page creation" and the attacker should not be able to create it. This occurs because of a mishandled distinction between an uploa...
CVE-2020-25812
PUBLISHED: 2020-09-27
An issue was discovered in MediaWiki 1.34.x before 1.34.4. On Special:Contributions, the NS filter uses unescaped messages as keys in the option key for an HTMLForm specifier. This is vulnerable to a mild XSS if one of those messages is changed to include raw HTML.
CVE-2020-25813
PUBLISHED: 2020-09-27
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, Special:UserRights exposes the existence of hidden users.
CVE-2020-25814
PUBLISHED: 2020-09-27
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, XSS related to jQuery can occur. The attacker creates a message with [javascript:payload xss] and turns it into a jQuery object with mw.message().parse(). The expected result is that the jQuery object does not contain an <a> ...