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 (at) greebo (dot) net [email concealed]> 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
>
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 (at) greebo (dot) net [email concealed]> 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
>
[ reply ]