Top 10 Ajax Security Holes and Driving Factors
by Shreeraj Shah - net square - Friday, 10 November 2006.
For example, consider this line of JavaScript code, Document.write(product-review)

Here, “Product-review” is a variable originating from a third-party blog. What if it contains JavaScript? The answer is obvious. It will get executed in the browser.

(6) Cross-domain access and Callback

Ajax cannot access cross-domains from the browser. One of the browser security features that exists in all flavors of browsers is the blocking of cross-domain access. There are several Web services that provide a callback mechanism for object serialization. Developers can use this callback mechanism to integrate Web services in the browser itself. The callback function name can be passed back so that as soon as the callback object stream is retrieved by the browser it gets executed by the specific function name originally passed from the browser.

This callback puts an extra burden on developers to have in-browser validation. If the incoming object stream is not validated by the browser then developers are putting the end client’s fate at the mercy of cross-domain targets. Intentionally or unintentionally, this cross domain service can inject malicious content into the browser. This cross domain call runs in the current DOM context and so makes the current session vulnerable as well. This entire cross-domain mechanism needs to be looked at very closely before implementation into an application.

(7) RSS & Atom injection

Syndicated feeds, RSS and Atom, are one of the most popular ways of passing site-updated information over the Internet. Several news, blogs, portals, etc. share more than one feed over the Internet. A feed is a standard XML document and can be consumed by any application. Web 2.0 applications integrate syndicated feeds using widgets or in-browser components. These components make Ajax calls to access feeds.

These feeds can be selected by end-users easily. Once selected, these feeds are parsed and injected into the DOM. But if the feed is not properly validated prior to injecting it into the DOM, several security issues can crop up. It is possible to inject a malicious link or JavaScript code into the browser. Once this malicious code injected into the DOM, the game is over. The end result is XSS and session hijacking.

(8) One-click bomb

Web 2.0 applications may not be compromised at the first instance itself, but it is possible to make an event-based injection. A malicious link with “onclick” can be injected with JavaScript. In this case, the browser is sitting on an exploit bomb waiting for the right event from the end-user to trigger the bomb. The exploit succeeds if that particular event is fired by clicking the link or button. This can lead to session hijacking through malicious code.

Once again this security hole is opened up as a result of information processing from untrusted sources without the right kind of validation. To exploit this security hole an event is required to be fired from an end-client. This event may be an innocuous event such as clicking a button or a link but the consequences can be disastrous. A malicious event that is fired may send current session information to the target or execute fancy inline exploit scripts in current browser context.


101,000 US taxpayers affected by automated attack on IRS app

The IRS has revealed more details about an attack it suffered last month, mounted by unknown individuals with the aim to file fraudulent tax returns and funnel the returned money to their own bank accounts.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.

Wed, Feb 10th