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.
