« previous 1 2 3 4

Igitur qui desiderat pacem, praeparet bellum

("Therefore, he who desires peace, let him prepare for war")

Attack vectors such as XSS and MITM are directed mainly against the client -- e.g. the users of Web 2.0 applications. However, the vulnerable frameworks discussed elsewhere in this article show that this does not mean that attacks against the server are completely unfeasible. The server element of an Ajax application takes input from an untrusted user and if this input is not assessed and filtered an attacker could inject and execute their own malicious code on the server. Canny attackers have yet fully to exploit server orientated vectors but classical remote code inclusion problems in PHP software due to register_globals=on for example, may well prove to be a fertile area for future research.

Assessing the security of deployed Ajax applications is aggravated by the fact that there are limited numbers of Ajax specific testing tools currently available. Of the tools that are available, many suffer from specific resource requirements. Sprajax (http://www.denimgroup.com/sprajax.html) for example, only functions in conjunction with an SQL Server 2005 database. Vendors such as Cenzic are making bold claims about supporting Ajax application specific assessment tasks in their automated vulnerability assessment applications [18].

The OWASP (Open Web Application Security Project) is developing a practical methodology and attendant assessment applications that will assist in the security audit of Ajax applications [19]. Until this is realised, the security professional may be in the unfortunate position of having to mould existing attack tools and methodologies or think laterally in order to discover flaws and vulnerabilities within Ajax applications.

Despite the current lack of testing tools and formal methodologies for assessing the security of Ajax applications, development teams should not ignore existing and emerging threats. As with the development of any application, security must play a pivotal role in the development cycle. If Ajax does prove to be all it has been hyped to be, a myriad of minds will undoubtedly be attempting to bring about its demise.[20] It remains the duty of the security professional and the seasoned developer to beat them to the punch. (Mike Kemp)

References:

[1] The article that started it all

[2] Document Object Model

[3] Technical explanation of the MySpace worm

[4] Description of JS.Yamanner worm on Secunia site, and the code itself.

[5] "Cross-Site Scripting: Data theft on the rebound", article on heise Security

[6] "Citibank Phish Spoofs 2-Factor Authentication", article on The Washington Post

[7] Example tool to help protect from attacks against SSL ciphers.

[8] "Securing Your Java Applications ", article on javalobby.org.

[9] "The Same Origin Policy", notes on mozilla.org.

[10] "On-Demand Javascript", description on ajaxpatterns.org.

[11] "XMLHttpRequest - Security Bypass", article on Julien Couvreur's programming blog.

[12] "FlashXMLHttpRequest: cross-domain requests", article on Julien Couvreur's programming blog.

[13] A relatively complete list of currently available Ajax frameworks

[14] Description of CPAINT, Cross-Platform Asynchronous INterface Toolkit.

[15] "Vulnerability found in CPAINT Ajax Toolkit", notes by Thor Larholm.

[16] "PAJAX - Remote (a)synchronous PHP objects in JavaScript", article on auberger.com.

[17] pajax_remote_exec, exploit module on metasploit.com.

[18] "Cenzic Extends Support for AJAX Security Assesment Applications", article on javascriptsearch.com.

[19] www.owasp.org/index.php/Category:OWASP_AJAX_Security_Project

[20] Wiki article on Ajax mythology

« previous 1 2 3 4