Slashdot Mirror
Top 10 Web 2.0 Attack Vectors
Fred writes, "HNS is running a story about Web 2.0 and the new attack vectors it opens up. Worms of the Yamanner, Samy, and Spaceflash types are exploiting client-side AJAX frameworks, providing new avenues of attack and compromising confidential information. On the server side, XML-based Web services are providing distributed application access through Web services interfaces and opening up new vulnerabilities in the process." The article is spread over 6 short pages and there is no printer-friendly URL.
> "The article is spread over 6 short pages and there is no printer-friendly URL."
;-)
Boy...I really hope Web 2.0 markup language allows for longer page length.
to build you a sand box to take care of all the new features but still protect your pc from all the evils of the world wide web.
Seriously, shouldn't 2.0 come equipped with some things that make it safer, not just more flashy?
Support NYCountryLawyer RIAA vs People
by Shreeraj Shah - net square - Monday, 9 October 2006.
Web 2.0 is the novel term coined for new generation Web applications. start.com, Google maps, Writely and MySpace.com are a few examples. The shifting technological landscape is the driving force behind these Web 2.0 applications. On the one hand are Web services that are empowering server-side core technology components and on the other hand are AJAX and Rich Internet Application (RIA) clients that are enhancing client-end interfaces in the browser itself.
XML is making a significant impact at both presentation and transport (HTTP/HTTPS) layers. To some extent XML is replacing HTML at the presentation layer while SOAP is becoming the XML-based transport mechanism of choice.
Web 2.0 security concerns - reshaping the industry
This technological transformation is bringing in new security concerns and attack vectors into existence. Yamanner, Samy and Spaceflash type worms are exploiting "client-side" AJAX frameworks, providing new avenues of attack and compromising some of the confidential information.
On the "server-side", XML based Web services are replacing some of the key functionalities and providing distributed application access through Web services interfaces. These remote capabilities to invoke methods over GET, POST or SOAP from the Web browser itself provide new openings to applications. On other side, RIA frameworks running on XML, XUL, Flash, Applets and JavaScripts are adding new possible sets of vectors. RIA, AJAX and Web services are adding new dimensions to Web application security.
Here is the list of 10 attack vectors along with a brief overview of each:
In the last few months, several cross-site scripting attacks have been observed, where malicious JavaScript code from a particular Web site gets executed on the victim's browser thereby compromising information. A recent example is the Yamanner worm that exploited cross-site scripting opportunities in Yahoo mail's AJAX call. Another recent example is the Samy worm that exploited MySpace.com's cross-site scripting flaw. AJAX gets executed on the client-side by allowing an incorrectly written script to be exploited by an attacker. The attacker is only required to craft a malicious link to coax unsuspecting users to visit a certain page from their Web browsers. This vulnerability existed in traditional applications as well but AJAX has added a new dimension to it.
XML traffic goes back and forth between server and browser in many of the WEB 2.0 applications. Web applications consume XML blocks coming from AJAX clients. It is possible to poison this XML block. Not uncommon is the technique to apply recursive payloads to similar-producing XML nodes multiple times. If the engine's handling is poor this may result in a denial of services on the server. Many attackers also produce malformed XML documents that can disrupt logic depending on parsing mechanisms in use on the server. There are two types of parsing mechanisms available on the server side - SAX and DOM. This same attack vector is also used with Web services since they consume SOAP messages and SOAP messages are nothing but XML messages. Large-scale adaptation of XMLs at the application layer opens up new opportunities to use this new attack vector.
XML external entity reference is an XML property which can be manipulated by an attacker. This can lead to arbitrary file or TCP connection openings that can be leveraged by an attacker. XML schema poisoning is another XML poisoning attack vector which can change execution flow. This vulnerability can help an attacker to compromise confidential information.
AJAX calls are very silent and end-users would not be able to determine whether or not the browser is making silent calls using the XMLHTTPRequest object. When the browser makes an AJAX call to any Web site it replay
Christ, my eyes started to bleed SOAP XML SAX AJAX WEB2.0 XMLHTTPRequestObject RSS
ojdsafdo fuck
As far as I know this can't be done with Ajax, since XHR can't make crossdomain requests. However there are other techniques for this, including hidden forms, iframes, images, etc. This is commonly known as Cross-site request forgery (XSRF) and is a major problem but not getting much publicity. I guess someone needs to write a MySpace worm that utilizes this technique before people start realizing it's a problem.
Most of those "attack vectors" boil down to injections and non-validated data, AKA "don't trust the user input". I don't know how they managed to multiply one single flaw into so many "vectors".
And there's also this "attacking scripts in RSS": what was this supposed to mean? My RSS readers don't execute script in RSS. No examples, no links.
One more talked about hijacking confidential information from a bank cookie. No example how this is done, just the author assumes we know how to automatically sniff the cookie, and that the bank doesn't use server-side sessions like 99% of them out there, but stores it all in a plain cookie.
Basically the article is not as fun or informative as the title suggests.
Ajax does not inherently introduce new security vulnerabilities into the realm of web applications. Instead, the applications face the same security issues as regular web applications. Unfortunately, common Ajax best practices have not been developed, which leaves plenty of room to get things wrong. This includes proper authentication, authorization, access control and input validation.
Consider the following:
- Ajax inevitably increases the overall complexity of the system.
- Typically, many web services within an enterprise (as opposed to on the Internet overall) were designed for B2B, and therefore designers and developers often did not expect interaction with actual users. This lack of foresight lead to some bad security assumptions during design.
- In the Ajax world, things can change much more subtly. The application can potentially generate different types of requests depending on the current state of the page. The request generated by clicking on a list box may be different from the request generated by clicking on the same list box if the user has first select a radio button on the page. Additionally, the response can update part of a page so that the user may now have new links or new controls to interact with on that page. During security testing, it is much more difficult to determine if the tester has seen all possible types of requests that can be generated by a page or application.
Conclusion
Ajax applications provide new possibilities through its highly interactive nature. Developers should be weary of new insecurities introduced by these capabilities. Security testers must augment their methodology and toolset to handle Ajax applications.
In order to detect these sorts of vulnerabilities in an automated fashion, there are only two decent approaches to choose from:
- Dynamic analysis: Feed the entire site, page by page, to a live browser and try to reproduce the XSS using a large number of browser actions as input. This is practically difficult and could also be quite risky (you can get owned yourself while doing it), and to get a good test you need to run a large number of inputs on several different browsers.
- Static analysis: Spider the site and run static analysis on the JavaScript on a page-by-page basis. This is much more promising, although obviously static analysis on a language like JavaScript, which is loosey-goosey with typing, is not trivial. Shameless plug: There are only a couple of tools which can do this: NeXpose from Rapid7 is one of them that I have worked on.
JSON itself is kind of cool, but many AJAX toolkits (including the one from Google) do AJAX/JSON things like:var result = eval(document.responseText)
which is a bit scary when you think that it may be possible to trick the server into emitting JavaScript (which, given the limited kinds of filterings that servers do, could be easier than tricking the server into emitting HTML).
Paper: Feed Injection In Web 2.0: Hacking RSS and Atom Feed Implementations, Robert Auger 2006
Blackhat Powerpoint Slides: Zero Day Subscriptions: Using RSS and Atom Feeds As Attack Delivery Systems (Power Point)
Additional Feed Security Documentation: http://www.cgisecurity.com/rss/
If you allow more stuff to be run client-side, you allow for more mischief.
Read radical news here
My THING might have some STUFF done to it!
These PEOPLE must be STOPPED before THE WORST happens!
If you want to know about web application security visit owasp.org