Top 10 Web 2.0 Attack Vectors 64
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.
pretty soon, you will need big blue (Score:4, Insightful)
Seriously, shouldn't 2.0 come equipped with some things that make it safer, not just more flashy?
Use good practices (Score:2, Insightful)
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.
Re:Off-topic (Score:1, Insightful)
Re:pretty soon, you will need big blue (Score:5, Insightful)
Re:No substance (Score:4, Insightful)
Not everyone's using an RSS reader from four years ago. =) Many RSS readers allow rendering of HTML. Heck, I'm using Bloglines, which is a web-based RSS reader; guess whether or not it supports HTML? However, it's up to the client to scrub the content properly and remove <script> crap.
Another question is, exactly how can you expect to launch an attack in a web feed? People use bazillion different RSS/Atom readers, and in many cases they're entirely separate from their web browsers...
Though, I hope people read the Atom spec [ietf.org] if they're implementing it, scrubbing HTML content is specifically addressed in the "Security Considerations": "Atom Processors should pay particular attention to the security of the IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and LINK elements, but other elements might also have negative security properties."
Re:No substance (Score:2, Insightful)
NO Surprise (Score:3, Insightful)
Re:pretty soon, you will need big blue (Score:5, Insightful)
You see it over and over again: Fantacy football sites that let you select players that aren't available by POSTing their id. A site that lets you delete your account but accepts the user ID you send in a POST without validating it (so replacing the ID with '%' deletes ALL accounts.)
These things should only be rookie mistakes. Yeah, validating data takes time to code. But if you don't do it you are just asking to be hacked.