Cross-Site Scripting Worm Floods MySpace

DJ_Vegas writes "One clever MySpace user looking to expand his buddy list recently figured out how to force others to become his friend, and ended up creating the first self-propagating cross-site scripting (XSS) worm. In less than 24 hours, 'Samy' had amassed over 1 million friends on the popular online community. According to BetaNews, the worm's code utilized XMLHTTPRequest - a JavaScript object used in AJAX Web applications and was spreading at a rate of 1,000 users every few seconds before MySpace shut down its site. Thankfully, the script was written for fun and didn't try to take advantage of unpatched security holes in IE to create a massive MySpace botnet."

Comments

Re:Day late, dollar short.

[Iriel]

These '/. is slow and stupid' kind of posts just need to stop. But I listen to 4 different tech podcasts and hadn't heard about this yet. Think about the people who check /. for news while they're at work and most likely away from iTunes and their bookmarks, and (god-forbid) without a readily accessible aggregator. Realize this site for what it is: for the majority of it, other techies posting news they've heard about to a community they might think will care to hear it. This isn't "news as it happens updated every second" so stop treating it like it is.

IE is too forgiving

[benhocking]

In the past, I've been of mixed feelings with IE correctly rendering the "intent" of a web-designer when the web-designer has created buggy HTML - this includes such things as omitting terminating tags (e.g., &ltl\li>) as well as a few other things. The result of IE doing this was that some web pages look good in IE that didn't look good in other browsers - thus encouraging more people to use IE. As HTML was being used more and more by the masses, there seemed some logic to this. Of course, one of the problems with this idea is that the designers were looking at their web-pages in IE to see if their code was written correctly.

This story just goes to emphasize the importance of calling buggy HTML code what it is, and not trying to infer the intent of the HTML coder. Samy cleverly found a way to make "buggy code" that would get past MySpace's filter, but that would be rendered the way he intended by the browser with the majority market share.

Re:IE is too forgiving

[Kawahee]

This exploit isn't limited to IE, Safari also has this problem. And I'd probably attribute it to 'logical' coding
pseudo-c code:

if (tagname == "style" && tagtype == "text/css") {

process_stylesheet (taginfo);

} else if (tagname == "style") {

switch (tagtype) {

case "text/javascript":

process_js (taginfo);
break;

}

}


But hopefully something less obvious that doesn't scream security flaw.

Re:Aww...

[maxwell demon]

Well, having over 1 million foes is also an achievement ...

Re:Well, people have been saying it's a security r

[-kertrats-]

They don't have javascript enabled. As far as I can tell, he just used IE's magical ability to run broken code so that the browser would be able to piece together the mess he used, but Myspace wouldnt be able to tell it was javascript.

Re:More info...

[Jerf]

And it gets through because stupid programmers persist in making two mistakes:

1. Defining "badness" instead of "goodness"
2. Trying to "clean up" invalid code

The first one means that you try to list all of the ways that the input can be bad. The Universe is evil and it hates you. You can't list all the funky things that it can do to you. Instead, list the good things and carefully verify that the input is good.

For a simple, but very very real-world example, don't write a rule that says "If the password contains /, =, or \, reject it." Write a rule that says "Passwords may contain only letters, numbers, and underscores." In the first case, especially in the brave new world of Unicode, you'll never enumerate all the bad things that can happen.

The second mistake is that once you've decided that input is bad, do not try to clean it up. The process of cleaning it up may itself make it invalid in the case of something like HTML. Just reject it with a good error message and let the user take care of it.

If that is absolutely impossible, preferably on the lines of "you'll be fired if you don't clean it up", then at the very least, you must continue to recursively run the cleanup code until the input converges (is unchanged by the cleanup code).

It's not that it's absolutely impossible to get it right if you don't follow these rules, it's just that it's really freakin' hard. Slashdot, for instance, does seem to manage, but it took them a few iterations and ultimately, it's a low-priority site even if it does get hacked a little. Is your program that unimportant?

It's way, way easier to define legit HTML (specific tags, no attributes usually though it's easy to let a few specific ones through, even with a handful of specific values) than it is to create a function to take any arbitrary string and make "safe" HTML out of it.