Jazoon ’09: Securing AJAX Applications
Session title: Securing AJAX Applications
Speakers: Moritz Kuhn, Philipp Färber – AdNovum Informatik AG
The subtitle of this talk is: “New threats and defenses?” Does the question mark imply that they will question the existence of new threats?
Speaker Moritz begins by citing some interesting attacks which took place recently, one of which took down myspace for a period of time – apparently using a simple JavaScript payload.
Proceeds to explain the “Same Origin” policy, which is designed to prevent a JS script in one frame from accessing the DOM in another frame. Note that this is enforced at the Window’s border. However, the rules are very complex and apply to cookies, XHR… and several other areas.
XMLHttpRequest has a stricter security model, which is often a pain for developers because it is inflexible, yet it is too loose for engineers because it is ambiguous.
Cross-Site Scripting (XSS) is an attack which exploits ambiguity in Same Origin rules.
Cross-Site Request Forgery (CSRF) when the victim is logged into an authenticated web application and his browser stores a session cookie for the app. The attackers web page makes the victim’s browser send a request to the vulnerable web app. The victim’s browser appends the cookie to the end of his request.
Speaker demos these attacks by showing how an attacking app can insert JavaScript code into a calendar; points out that the code could contain anything… reading email for example. Scary stuff!
How to combat these threats? Philipp takes to the stage…
Begins by contrasting classic and AJAX architectures, which increases awareness of the technical interactions involved between the parties.
Looking from the server-side, need to consider that the attack-surface is increased in an AJAX architecture e.g. via exposed services, protocols, sessions, domains. Also: code contains call params and service URLs. Finally, there are concurrency issues.
From the client side, new attacks are around like JSON hijacking and DOM-based XSS with URl fragments.
A final observation from the speaker is that one of the consequences of all this is that testing is getting harder. Exhaustive testing is obviously out of the question.
Counter-measures:
Input validation, output encoding, service hardening. Retain awareness of the technologies you are using. Defensive design involves avoiding mashup-like services, KISS and using separate domains for public and private data. Points out the fact that the Google domain strategy is open to XSS attacks.
Some AJAX-specific counter-measures: Know the output’s insertion context (don’t allow angled brackets in the output, for example!); Ensure no sensitive data is sent to the client (be aware what your frameworks are sending!); Prefix all JSON replies e.g. ‘while(1); {“x”:”y”}’; Add a random number to a response and match it up when the next request comes in. This can’t be predicted in advance by an attacker (I like this!); Validate services responses – also in the client; Understand and use a secure framework e.g. GWT, prototype, jQuery…
Rigorous testing is obviously a must; Designing for security/testing upfront is a must; Test individual AJAX features individually; Simulate malicious requests…
Conclusion: AJAX means: Old threats + new threats + higher complexity = bad news.
Summary: I never cease to be shocked by the degree of details and complexity which the developer has to be acquainted with in order to make an AJAX-based app secure. The reality of AJAX development is that in most projects the developer will be focussed on delivering the the core business requirements and getting the look and feel right. With this focus security holes are virtually inevitably.
A very worthwhile presentation!
