Web 2.0 and AJAX Security Vulnerabilities

Ajaxian has a post about some sessions at the Black Hat USA 2006 conference. I’m quite honestly surprised that this is just gaining some press now, I’ve figured it would happen sooner than it has (but that’s typical for me I posted on this a while back, and I haven’t seen much improvement in this area since.

There are so many ways to break an application it’s not even funny. I wouldn’t consider a Web application secure unless it (and the company that provides it) have adequate answers to the type of security scrutiny that Sarbanes-Oxley typically requires.

On top of that, however, AJAX programming techniques do a few other things that make it easy to break applications and/or intercept sensitive data:

LOTS of Web 2.0 applications use GET instead of POST to transmit data, and that means that any ID’s or commands that are in the querystring are available in plaintext to anyone who wants them. (POST’s are vulnerable too, but not quite as easy to intercept). If there’s not a solid authentication mechanism underneath such as Digest authentication, man in the middle attacks become a piece of cake. Somebody could easily sniff messages and pretend to be you.
XmlHttpRequest calls (at the core of most AJAX apps) can easily be interecepted unless they’re encrypted with SSL, which almost none are. That means that pretty much anything you input into a Web 2.0 app is fair game for somebody sniffing HTTP on the network.

Part of the reason I’ve been so quiet on my blog lately is because I’ve been wrestling with this very problem. I absolutely love everything AJAX has to offer, however sending naked data back and forth from the server is a pretty huge problem. I also don’t like the idea of securing the entire site with SSL as that’s a huge burden on the server. What I’m currently working on (as part of a much larger probject) is a comet implementation that streams messages over SSL in an unsecured page so that only messages going back and forth from the server are encrypted. I believe it will work, but it requires a backend server to receive and queue messages which has to be built first (similar to cometd). I’ll post more about it when there’s something to show.

Share and Enjoy:

http://xmlhacker.com M. David Peterson

I was wondering recently if you were still alive!

Glad to see the answer to this is "yes"

Some *REALLY* good points! Looking forward to the results of your work. Should be some interesting stuff, as usual
http://profile.typekey.com/jasonkolb/ jasonkolb

LOL Yes still alive, just burying myself in Jabber specs for the past few weeks thanks to you But seriously, the end result of what I'm working on right now should allow us to securely stream blip messages directly to Javascript, so that will make for a pretty cool proof of concept once I get it up and running in the next week or two. Not dead, just reading and coding a lot
http://xmlhacker.com M. David Peterson

>> Yes still alive, just burying myself in Jabber specs for the past few weeks thanks to you

I feel just horrible

>> securely stream blip messages directly to Javascript, so that will make for a pretty cool proof of concept once I get it up and running in the next week or two.

NICE! I can't wait to see it

>> Not dead, just reading and coding a lot

Ahh.. Know the feeling well

Lots happening behind the scenes on several fronts. Lets catch up in email as soon as you have a chance.
Michael Poulin

Here is a question, folks, about Comet security, in particular, Server streaming pattern. If upon XmlHttpRequest call, the server starts stream data to the browser for some period of time, how the server gets sure that the listener to this data is the browser which initially requested the data?

Yes, I am talking about bi-directional authentication for each stream portion sent separately. Isn't this a new threat for stream-based Web applications (though it is well-known for distributed systems)?

- M.