« previous 1 2 3 4 next »

Be careful what you wish for...

One claim made of Ajax security is that the threats from phishing and MITM attacks are greatly reduced by the implementation of the XMLHTTPRequest object. Unlike traditional JavaScript, the XMLHTTPRequest object is not allowed to make cross domain, cross port, or cross protocol requests. Although this can limit casual attacks, it can also make the development of cross site applications a challenge. There are a number of potential solutions to the challenges posed by the use of the XMLHTTPRequest object and the limitations of the same original security policy [9].

The simplest mechanism for bypassing restrictions posed by the XMLHTTPRequest object when seeking to request information from an external domain source is to request a URL that is hosted on the same domain, but utilises a scripting language (e.g. PHP) to parse the data required from the 'blocked' external domain. Another mechanism utilises On-Demand JavaScript [10]. By using cross domain scripting, developers can trivially access external content. However, the use of this technique is not without considerable risks as any scripts that are executed are done so with the same authority as scripts on the base page, and the potential for security incidents is considerable. The use of cross domain scripting is best avoided. These aren't the only mechanisms available to the struggling developer however, and the French software engineer Julien Couvreur has already invested considerable time bypassing the limitation of the XMLHTTPRequest object using both Greasemonkey [11] scripts and Flash [12]. It's not just developers that can bypass the resilience of the XMLHTTPRequest Object; attackers have found numerous ways to utilise it. A number of flaws in both Opera and Mozilla browser implementations have been disclosed publicly. Browser security mechanisms may not allow developers to make requests to external domain resources using the XMLHTTPRequest object (unless they implement one of the bypass mechanisms discussed above) but this may not stop a determined attacker. Assume you have a sub-domain on your site {e.g. www.mybank.com has the sub-domain accounts.mybank.com). If the sub-domain (or even top level domain URL) is vulnerable to script injection, an attacker can bounce XMLHTTPRequests around the domain with impunity, and depending what validation checks are in place, gain improper access to data. Just in case you are sceptical enough to believe that attackers aren't already thinking about security deficits within XMLHTTPRequest objects, a quick read of this Darknet article is in order.

Framed

Since Ajax was unveiled as a developmental concept, numerous toolkits and Ajax related frameworks have emerged. The rate of release for such frameworks and toolkits has been rapid, and as yet shows limited signs of slowing [13]. Obviously any applications that are developed using these frameworks may well inherit shared security flaws, and such attacks present an attractive proposition for both the security researcher and the malicious attacker. The reason for this is simple enough; for the malicious attacker a successful attack against a popularly deployed framework or toolkit can often lead to successful attacks against potentially hundreds of sites that have been developed using common functions.

The decision of which framework or toolkit to employ is an important one with regard to security concerns. As the majority of framework environments and toolkits are as yet largely unproven (many are still in beta), and the security implications of their functionality is a largely unexplored variable, the risk management process must play a central role in their selection.

Although limited legitimate research has been conducted into the large (and increasing) number of Ajax frameworks and toolkits, it is not a completely barren area. Last year, a number of issues were discovered in the comparatively popular Ajax toolkit CPAINT (Cross Platform Asynchronous Interface toolkit)[14]. The vulnerabilities disclosed ranged from simple cross site scripting to insufficient function security that could be exploited to execute malicious code. In the most critical of the vulnerabilities provided by researcher Thor Larholm an attacker does not even require a valid name for a predefined function to execute malicious code.[15]

Earlier this year, a number of flaws were discovered in the Ajax framework PAjax [16]. As with the most pronounced of the vulnerabilities within CPAINT, vulnerabilities relating to insufficient input sanitisation and validation led to a situation whereby malicious code could be executed by an attacker. More worrying still for those developers who have utilised PAjax as a means of quickly developing Ajax applications, in May of this year a metasploit module [17] was unveiled targeting the disclosed vulnerabilities making potentially hundreds of new Web 2.0 applications vulnerable.

« previous 1 2 3 4 next »