Andrew,
There was a great discussion about EXACTLY this on webapp and pen-test
lists (securityfocus.net). I suggest you google it. It was very
informative.
I remember it mentioned something about Googles implemintation of AJAX
(earth) and that they did not send raw XML as such but a pre-made JS
object. It was authenticated via some sort of ID. I dont recall how ID
itself was generated but that was a very nifty idea of AJAX security
(since i remembered it incase I was doing something similar), maybe
worth looking into it.
Also link below might help:
http://sourcelabs.com/ajb/archives/2005/05/ajax_mistakes.html
Hope I helped,
Serg
On 23/09/05, Andrew van der Stock <vanderaj@greebo.net> wrote:
Hi there,
I am writing a section on AJAX for the OWASP Guide, and since it's so
shiny, I'd thought I'd run my thoughts past you folks.
1. It's Web Services Lite.
(Spoofing)
Therefore, many of the issues facing unauthenticated web services
apply to Ajax, too. If you are using AJAX without session management,
it should be unable to perform any tasks a guest cannot do.
2. Validate like crazy
(Tampering)
Just because the process is hidden from the user, doesn't mean that
the incoming request is safe to handle without validation. Validate
all inbound requests properly.
3. SSL when necessary
(Repudiation)
Ajax may not be visible to the user, but it still exposes the user to
confidentiality attacks if sensitive information is transmitted in
either direction. Use SSL to protect privacy and integrity, whilst
realizing that SSL is not "security" in and of itself.
4. POST please
(Information Disclosure)
Again, it's easy to use GET, but this remains in the browser history
and many intermediate logs.
If the Ajax request allows you to fill in information about another
user, make sure the caller is authorized to receive that information.
For example, if you provide an Ajax request to find all posts by a
user on a forum, make sure the posts are filtered to only include
those the user would normally be able to see, or if you are writing a
transaction history query, make sure the query only runs against
accounts the user has access to.
5. Simple and fast handling
(Denial of Service)
Ajax could be used as a DoS target, particularly, if the requests are
doing significant chunks of work for unauthenticated clients. Be
careful about implementing long running tasks, which is a typical
scenario for Ajax (do something slow behind the user's back, to make
the page feel fast).
6. Ensure the Ajax path is properly access controlled
(Elevation of privilege)
Ajax is a relatively new technology with many immature
implementations. Make sure that all requests are properly
authenticated and authorized to prevent users performing tasks which
would allow them to become higher privilege users than they already
are. For example, don't allow Ajax to perform administration tasks
for just anyone.
--
Thoughts?
thanks,
Andrew
