« previous 1 2 3 4 next »

MITM: The Kissinger of Attacks

As most data that is transmitted by an Ajax application occurs over HTTP in plain text, Ajax applications are open to potential man in the middle (MITM) attacks.

It is a common misconception that MITM attacks are largely the stuff of conjecture, but there exist a number of related attack vectors (and tools) available to the attacker seeking to target an Ajax application without SSL implemented, and with conventional web applications there has been a host of successful attacks. Although MITM attacks are common at a network level, they are also often used as an attack vector against web applications (Ajax or not). In a typical MITM attack, an attacker makes a legitimate copy of an existing web application, directs users to it, traps their requests to the server, stores a copy, and then redirects to the legitimate application. Obviously this is an attack vector most popularly employed in phishing attacks, and phishers recently exploited similar techniques to bypass much touted two factor authentication [6].

Consider a shopping portal developed as an Ajax application. Just as with a traditional web application, attackers could establish a copy of the application (or more specifically the payment options) and then trick users into utilising it and parting with payment/banking details. Thanks to the asynchrous nature of Ajax applications it may also be possible to spoof the source of Ajax data, and replace legitimate application components with those of a more dubious and malign intent.

Just as with traditional web applications however, HTTP requests and responses sent via an Ajax application can be wrapped in SSL. Although by no means a foolproof solution to MITM attacks [7], this is a simple mechanism for increasing the security posture of an application. It should be remembered that much energy has been focused on developing successful attack vectors and tools for use against applications that use SSL, and even a cursory Internet search reveals that researchers and blackhats alike have not wasted their efforts. Indeed, several years ago, SSL 2.0 was found to be vulnerable to a host of MITM attacks. So when considering SSL, the very least security consideration is to utilise SSL 3.0 cryptography and TLS 1.0.

Ideally the dynamic code base that is served from an application to an Ajax client should have restrictive access. As Ajax is limited only to permitting communication via HTTP, and although introducing Secure HTTP can assist in limiting casual access to individual data transactions, it cannot be implemented as a mechanism used to determine who or what can call to a particular URL. The XMLHTTPRequest object does provide granularity however, and developers should ideally consider either filtering HTTP requests, employing the HTTP session or employing encrypted HTTP headers to prevent malicious access requests (many technologies exist to accomplish such aims[8]).

New Apps, Old Tricks

Because Ajax is a framework that is based upon existing standards, and implementations of it are based around conventional web development techniques, Ajax applications also have a number of security issues that are shared with all web applications.

One security issue to consider is that if an Ajax application routine is poorly designed or implemented it has the potential to be used to launch a successful DoS attack against the application server. Many current web applications and servers are attuned to a certain number of users performing a certain number of actions over a specific time frame. Imagine a scenario whereby application developers embrace the asynchronous nature of Ajax, and allow a form to be auto filled based upon select user input. Rather than cache data on either client or server, a small Ajax control directly polls the database. Obviously this increases the requests made and has the potential to produce a server load that the server (and/or session) may not be able to handle. If proper care is not taken, applications could be comparatively trivial for an attacker to force offline, and just as in myth, Ajax can be used against itself.

A major issue with Ajax is that it affords an attacker an increased field of attack. Developers may choose to implement server-side pages that perform limited functionality in support of the application. Although these server-side pages will be restricted in the actions that they may legitimately perform, they may provide an attacker with an increased area of attack, and will need to be as carefully secured as the rest of the application. Another area for concern is error handling. In many traditional web applications this is an overlooked area and in the rush to create the next world beating application error handling may well be overlooked by time pressured development teams. The correct handling of errors is beyond this scope of this article, however, Ajax development teams should strive to ensure that an application errs gracefully, as this is certainly one attack vector that will attract attention.

« previous 1 2 3 4 next »