Here's an interesting article sent to me by my esteemed boss; but it doesn't precisely describe the Web 2.0 threat.
"
http://sfgate.com/cgi-bin/article.cgi?f=/c/a/2007/07/30/BUUSR98VI2.DTL"
My thought is that the prime vulnerability in Web 2.0 (aka AJAX) is allowing AJAX calls to the server that change data without authenticating the request. Another vulnerability is if someone logs into the app, then leaves to a malicious site, and that mal-site (did I just make a new term there?) does an AJAX call to our server using the user's legitimate auth cookie.
What to do? Verify the request of course. If your user request came in from some IP, verify that IP the next request. If it changes raise an alert. But IPs can be spoofed. Next line of defense is the rest of the HTTP data. Did the agent change? Were they using FireFox, but suddenly your getting a "curl" request? Did the language change from 'en-US' to something else?
You can follow this "white rabbit" a fairly long way. Of course all this added security verification will come at a cost. Additional data stored in your sessions, which could be DB records, files or a caching server. Added latency to the calls while this security work is done. Thus I wouldn't bother with this security for internal applications sitting comfortably behind the lock-solid IT-managed firewall. But, engineers developing web apps that will live on the wild open-web should think long and hard about these issues, lest it be your paying customers whose credit cards are pilfered.
Before I go, I don't want to neglect the "GETs should be safe philosophy". Don't have an HTTP GET request doing data changing operations within your application. This is just bad design that mis-uses the HTTP protocol.
