Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

RE: Ajax Security discussion for the OWASP Guide

Subject: RE: Ajax Security discussion for the OWASP Guide
Date: Fri, 23 Sep 2005 09:35:26 -0400
It might be nice if the Guide discussed other technologies similar to AJAX,
like JSON-RPC, MS-Altas, Seaside, etc.  I think that many of the issues will
be similar, but maybe not?

Luke

-----Original Message-----
From: Andrew van der Stock [mailto:vanderaj@greebo.net] 
Sent: Thursday, September 22, 2005 9:45 PM
To: webappsec@securityfocus.com
Subject: Ajax Security discussion for the OWASP Guide

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

<Prev in Thread] Current Thread [Next in Thread>