Web 2.0 Attacks

A good article on the ways to attack a Web 2.0 application, thanks to the growing number of technologies used in "rich internet applications" (html, flash, applets, javascript, etc):

1. Cross-site scripting in AJAX. A pre-AJAX browser exploit, but AJAX makes it easier to hide such an attack.
   
2. XML poisoning. A denial-of-service attack that tries to exploit weaknesses in server-side XML parsers. Do something nasty like apply a recursive payload to an XML block.
3. Malicious AJAX execution. Some javascript that sits in the background, captures info from a server (e.g. the user has signed into their on-line bank account) and sends that info to a identity theft server. All done silently.
4. RSS / Atom feed injection. RSS is becoming a popular distribution mechanism. Since most people view feeds in their browser it becomes very easy to slip some malicious javascript into a feed.
5. WSDL scanning and enumeration. Looking at the exposed method interfaces of a web service a malicious person may be able to guess at ways to atack the interface. e.g. if you see a "debug" or "override" parameter you might be tempted to see what it does.
6. Client side validation in AJAX. For those people who define validation on the client side but are too lazy to do the equivalent validation on the server side, don't be surprised if someone breaks your application by making a malicious call directly to the server.
7. Web services routing issues. WS-Routing allows SOAP messages to travel in specific sequence from various different nodes on the Internet. Often encrypted messages traverse these nodes. A compromise of any of the intermediate nodes results in possible access to the SOAP messages traveling between two end points.
8. Parameter manipulation with SOAP. Try manipulating the values of the SOAP messages to do things like SQL-injection attacks.
   
9. XPATH injection in SOAP messages. ditto to the point above.
10. RIA thick client binary manipulation. An attacker can reverse engineer the binary file (e.g. flash .swf files) and decompile the code.

Update: DLG asked what are some guidelines to protecting against such attacks? Some of my thoughts are:

• AJAX calls only work cross-site if using iframes. As with javascript the browsers should pop us a security alert asking if cross-site AJAX calls should be allowed on the page.
• XML Poisoning / Parameter manipulation / XPATH injection. You should unit test a number of such attacks to see what happens. You may need to work with your vendor to fix any issues in the XML stack they provide.
• WSDL scanning. A code review should find any methods that should not be exposed to clients. What could make this tricker, however, is that many of the SOAP standards now use a document-centric approach, where the WSDL is a thin wrapper around an XML "blob" payload.