The AJAX Application Delivery Challenge

Web 2.0 technologies like AJAX can have far-reaching consequences when it comes to security and performance


January 08, 2007
URL:http://www.drdobbs.com/web-development/the-ajax-application-delivery-challenge/196801933


Users are demanding rich, interactive browser-based applications. Security administrators require these applications be secure on both ends of the wire. Server and systems administrators insist that the application not consume more than its fair share of resources, and network administrators are eyeing up your application and calculating the charge-backs with a gleam in their eye, wringing their hands gleefully while anticipating the probability of funding their next upgrade based solely on the cost of bandwidth needed to deliver your application.

While Web 2.0 technologies like AJAX ("Asynchronous JavaScript and XML") provide the means by which you can satisfy the demands of your users, these emerging technologies can also have far-reaching consequence in terms of security and performance. Advocates of Web 2.0 technologies like AJAX like to point out that AJAX requests are typically smaller than their traditional HTML counterparts, but they forget to mention there are more of them, more often. Developers using JSON ("JavaScript Object Notation") as their protocol of choice to exchange messages between the browser and the server like to claim it is a "fat free" alternative to XML, but in reality the FDA would call them out on that claim, not to mention the security risks inherent in using JSON that aren't present with its XML counterpart.

With more data being exchanged at a faster rate, no standards support, immature toolkits and human-readable application logic, AJAX has a plethora of application delivery and security hurdles to overcome. AJAX isn't going away. In fact it's being adopted at an incredible rate by internal developers and ISVs alike, therefore addressing the performance and security concerns of this fledgling technology is necessary sooner rather than later.

The key to a successful deployment is to understand and address the performance and security issues up front, rather than taking a laissez-faire approach to the whole thing and waiting until someone complains or disaster strikes. By understanding the challenges inherent in Web 2.0 technologies like AJAX you can avoid the performance and security pitfalls that may crop up along the way.

AJAX and Application Performance

The network guys have a secret they don't want you to know: The computational cost of TCP session setup and teardown is high, second only to application processing time in terms of its effect on the overall response time of your application. Every connection made by a web browser to the server requires an underlying TCP session, and it is time consuming to both client and server.

HTTP 1.1 dealt with this issue by introducing pipelining of HTTP requests over an existing TCP connection, ostensibly reducing the number of connections necessary to load a web page. In a sort of Moore's Law like phenomenon, as performance improved pages again grew even fatter, requiring even more requests and more bandwidth.

But HTTP 1.1 says that clients should not open more than two connections to a server, and by default Internet Explorer adheres to the specification. While pipelining of HTTP requests is advantageous in terms of minimizing the impact of connections on the server, it isn't so great for the end-user and the "slow" rendering of large pages within Microsoft's browser is primarily due to the limitation on connections and not any specific deficiency with the underlying code. The specification was written with the performance of servers, not clients, in mind.

AJAX is exciting because it provides the means by which developers can limit the initial amount of data transferred to the client, pre-fetch data and images to enable a more responsive experience, and silently load data during the session that is unique to the user's interaction. AJAX-based applications are not page-centric, they are component centric. This allows browser-based clients to act more like their fat-client counterparts, offering an interactive experience that doesn't require a constant refresh.

This does result in fewer total page refreshes, but requires a great deal more application logic on the client to manage additional connections to the server and exchange data at the appropriate times, such as when the value in a list box changes or a new tab is selected.

The problem with this model begins to manifest itself in the communication channel underlying AJAX requests. Developers taking advantage of libraries like Dojo or Zimbra rely upon these toolkits for the basic format of data being exchanged - and rarely have control over that format. The toolkits are great for enhancing developer productivity but poor at enabling developers to understand and control the exchange of data. The data is usually exchanged using XML, with no defined schemas against which messages can be validated, leaving applications vulnerable to a set of XML-borne web attacks that are easily prevented simply by tightening and enforcing a well-defined schema.

Also problematic is the refresh rate of AJAX-based components. AJAX makes it a simple task to not only build interactive interfaces, but to provide a near real-time experience for the user. AJAX doesn't solve the inability of the server to push data to the client, therefore applications remain reliant on polling to update data.

The refresh rate can impede performance in multiple ways. First, it maintains an intermittent flow of data between the client and server. Depending on the refresh rate this can cause any number of performance problems. If it's too high and exceeds the browser's default idle time out value (1 minute for Internet Explorer), then the additional performance penalty incurred by establishing a new TCP session with every request drives up response time. This is also true of normal requests made via JavaScript -- if the user is idle too long, a new connection will need to be established. If it's too low and the user is on a WAN or slow link, the requests can begin to overlap and the client will be constantly sending and receiving requests at ridiculous rate.

In addition to the performance implications on the client, the server also has to maintain more connections for longer periods of time and it may not be optimally tuned to handle the additional burden. Web servers were meant to serve content in a request-reply paradigm. Although AJAX complies with the paradigm, it does so in ways that were not anticipated by those who penned the HTTP specification by reusing the connection over long periods of time.

To address the potential performance pitfalls you'll need to tune your web server accordingly. There are a limited number of parameters you can tune to assist in improving performance of AJAX-based applications and they are tactical, stop-gap solutions rather than strategic, but they might tide you over while you search for long-term solutions.

Even after tuning your web server you may find that your users experience inconsistent performance and your web server may be experiencing undesirably high CPU utilization rates. You may run into an artificial simultaneous connection limitation set by the web server or you might know that additional AJAX-based applications are coming and you need a more robust and widely applicable solution. If that's the case, you'll need to turn to an external solution such as application delivery controller.

An application delivery controller addresses these performance issues by providing optimized TCP and HTTP stacks capable of handling the higher request rate in a more efficient manner. Such devices provide a more consistent user experience because they are capable of optimizing communication between the client and server as well as providing better management of the resources available on the server by being aware of the state of the server and managing requests and responses appropriately. One such feature provided by these devices is request throttling, which limits the number of times per session, per user, or per second that a request can be made.

Application delivery controllers that act as a full proxy are also capable of servicing more clients while maintaining a lower number of connections to back-end servers, essentially cutting the number of connections to servers in half. This feature lets you provide consistent application performance to more clients without deploying additional servers.

These devices are also aware of the bandwidth available to the client and can adjust the rate of delivery accordingly while allowing the server to deliver content at the highest rate possible. This means the server can deliver content as fast as possible and does not need to tie up a connection while it waits for a client on a slow link or device (WAN, dial-up, mobile devices) to receive the data. This can also eliminate the possibility of needing a second, third, or even fourth web server to handle the increase in requests created by AJAX and Web 2.0 applications.

Security Risks

AJAX-based applications are particularly susceptible to a number of traditional and new web-based attacks such as man-in-the-middle as well as unauthorized access to the scripts and processes that handle AJAX requests. This is not because it makes this type of attack any easier to perpetrate, but is due to the technology's reliance on JavaScript and its "under-the-covers" nature. Many toolkits do not provide a mechanism for passing credentials, so such data must be somehow embedded in requests or ACLs placed on each script that take advantage of HTTP Basic authentication mechanisms automatically.

The most obvious security risk with AJAX is there is little or no content inspection, which can lead to the injection of malicious code with relative ease on both the server and the client. Toolkits taking advantage of JSON (JavaScript Object Notation) are particularly susceptible to the injection of malicious code as the JavaScript engine on the client responsible for evaluating replies in the form of JSON does not validate the JavaScript returned from the server -- it simply evaluates and executes the response.

If data is exchanged in XML format, there is no way to protect against XML-based attacks such as DoS in the form of oversized messages, entity expansion attacks, or the injection of malicious system or database level code. This is because there is no schema against which the XML can be validated, and thus no clear description of the types of elements that should or should not be present in the exchanged data. The developer is responsible for pre-parsing the data to ensure that XML-borne attacks are not present, and then must devise a mechanism for determining whether the XML contains more insidious attacks such as entity expansion -- a task that is exceedingly difficult due to the sometimes recursive nature of XML documents.

Using a toolkit also increases the possibility of unauthorized access to back-end systems because it is rare that a developer will add-in access control to the scripts used to communicate with AJAX-based interfaces. Forceful browsing can be used to locate and then execute back-end scripts that have weak or non-existent security mechanisms to prevent unauthorized access. Taking advantage of cookies or server-side ACLs diminishes only a portion of this risk, as cookies can be tampered with or poisoned, and ACLs are often applied inconsistently during deployment.

It is rare that developers -- whether using a toolkit or coding his own AJAX-based communication -- can address every potential security risk inherent in the technology. There is simply not enough time in the day for the developer to code and test the core application in addition to becoming a security expert. Similarly it is not likely that security experts within the enterprise will become AJAX or XML security experts over night.

Fortunately for both groups web application firewalls have evolved and now include the ability to secure and prevent attacks against AJAX and other XML-based attacks. While many developers might prefer to code such security into their applications, it is impractical to dedicate a developer resource to updating an application every time a new attack is discovered. A web application firewall or XML firewall prevents existing and emerging attacks from reaching the application server, thus eliminating the majority of AJAX and XML-borne attacks from adversely affecting internal application infrastructure. These solutions are certainly not all inclusive, nor are they meant to replace existing secure development practices, but they can augment existing security policies by putting into place a first line of defense that will prevent the majority of malicious traffic from reaching the application, thus leaving the developer with the time to concentrate on enterprise specific security issues.


Lori MacVittie is a Technical Marketing Manager for F5 Networks.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.