Fwd: Security problems with Ajax

[vanderaj at greebo.net (Andrew van der Stock)]

Hi there,

I replied to Kentaro privately before I was subscribed to this list.  
The OWASP Guide 2.1 Ajax chapter is about 80% done and 80% to go. I  
have some serious vulnerabilities to report to a few vendors,  
research to be included in the paper, such as JSON injection and so  
on, and peer review from an accessibility expert (as I'm not  
qualified in this area).

My slide deck from the OWASP Melbourne chapter meeting in February is  
also useful:
http://www.greebo.net/owasp/ajax_security.pdf (PDF, 1.8 MB)

Here is my message to Kentaro-san:

Begin forwarded message:

> From: Andrew van der Stock <vanderaj at greebo.net>
> Date: 7 March 2006 2:54:36 AM
> To: kentaro.arai at <hidden>
> Subject: Security problems with Ajax
>
> Kentaro,
>
> In short, yes! :)
>
> I am researching and writing a new chapter on Ajax security for the  
> OWASP Guide which will be out as soon as it's been properly  
> reviewed. In my travels, I've found many implementation issues  
> surrounding how Ajax toolkits are used.
>
> In particular:
>
> a) security architecture. Where to start... please read the chapter  
> when it comes out
>
> b) sending to a second, disassociated server prevents secure state,  
> such as authorization from being shared. This usually leads to  
> really poor decisions about state management and application design
>
> c) insecure client-side state storage - including authorization  
> decisions
>
> d) client-side authorization (!!!) or non-existent authorization (!!!)
>
> e) new classes of injection attacks (which I call "Ajax injection"  
> as a meta-class of attack, but are in fact a multitude of injection  
> attacks including existing issues such as Javascript code injection  
> (as per GMail last week) and basic XSS, through to JSON injection,  
> which is a new one) due to a lack of care with encoding, decoding,  
> and in general simply not thinking things through
>
> f) insufficient validation on the server, particularly when Ajax  
> calls web services, and even more so when Ajax calls enterprise  
> service buses (SOA) publishing 40 year old COBOL code which has  
> never been tested for XML node injection before
>
> g) insufficient business rule validation. This is true of normal  
> apps as well, but it is particularly prevalent with Ajax apps as  
> for some strange reason they believe Ajax is secure magic pixie  
> dust. I've got a few demo vulnerabilities to report to various  
> places before I can speak about these in the open.
>
> h) GET request mania. I know that someone here posted something  
> about REST, but honestly, GET methods is a privacy nightmare for  
> many firms who must go out of their way to prevent private  
> information leaking into third party systems like ISP caches or  
> browser history on Internet kiosks. Only a few toolkits had clear  
> documentation on how you can change to using POST data... which  
> surprisingly includes CPaint, one of the first Ajax toolkits to be  
> exposed as insecure. Version 2.0.x of CPaint is soooo much better.
>
> h) not particularly security related, but is compliance related -  
> Ajax frameworks are in general completely inaccessible. They fail  
> WAI validation miserably, do not provide alternate accessible  
> paths, and rarely prompt screen readers to refresh the screen. Many  
> are fixed pixel sizes and work in new ways which makes using  
> assistive technologies impossible as they don't know how to handle  
> this bag o' pixels masquerading as an application. I am getting  
> this section peer reviewed by an accessibility specialist, but as  
> it's illegal to produce inaccessible applications unless it's a  
> justifiable hardship (gee, spending 20%-90% more to create a glitzy  
> interface over an accessible one will go down well with our equal  
> opportunity legal beagles). Ajax CAN be accessible. But with few  
> exceptions, it is not. In some hard core cases, the vendors must  
> really hate and despise disabled users and users with high DPI  
> screens. I have one major commercial Ajax vendor suite that acts  
> like its own desktop UI that *crashes* the browser when you try to  
> increase the font size to something readable. I will name names  
> soon if they don't get their act together. Completely and utterly  
> unacceptable.
>
> In short, Ajax can be made secure, but in general it is not -  
> application writers are at worse than security square one with most  
> toolkits. The architecture alone forces many poor choices upon  
> application authors, and if they are unaware of security issues,  
> they will create insecure and unsecurable web applications.
>
> thanks,
> Andrew