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 <[EMAIL PROTECTED]>
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
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
