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.

Comments

pretty soon, you will need big blue

[zappepcs]

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?

Re:pretty soon, you will need big blue

[ElleyKitten]

Seriously, shouldn't 2.0 come equipped with some things that make it safer, not just more flashy?

Uh, "Web 2.0" isn't a product. It's a buzzword for flashy things, so it makes sense that it doesn't "come with" more security.

Re:pretty soon, you will need big blue

[k12linux]

Most of these come back to developers violating one of the key rules of web application development (from the web 1.0 stuff as well.) DON'T IMPLICITLY TRUST DATA YOU GET FROM THE CLIENT!

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.

Use good practices

[Anonymous Coward]

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.

Re:Off-topic

[Anonymous Coward]

Um.. in case you didn't know, the printer-friendly URL is favored by /.ers because it's usually not spread over those 6 pages, and there isn't the ton of ads that make them want to chop it up to get you to read 6x as many in the first place. In other words, it's possible to read TFA without hating life.

Re:No substance

[WWWWolf]

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.

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 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

[profplump]

No, but like every decent password-update system written since 1967, it does require me to enter my old password before I can choose a new one. Likewise, transfers and bill payments all require both an input and a validation step, in seperate page submissions, and the validation step includes a unique transaction ID. Could a sufficiently advanced JavaScript overcome these limitations? Certainly, but it's not as trivial as having a valid session ID and blindly submitting a form.

NO Surprise

[unity100]

If you allow more stuff to be run client-side, you allow for more mischief.