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."
Is this the first AJAX vulnerability? Something like this would be expected in any new-ish tech that is increasing in popularity.
the problem here is they let users render html & javascript in their own pages on the site
No, the problem is that they let users render html & javascript badly in their own pages on the site
"He hated Mexicans, and he was half Mexican. AND he hated irony!"
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.
Perfecting Discordia
www.stevenvansickle.com
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., <l\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.
Ben Hocking
Need a professional organizer?
This was bound to happen sooner or later, as MySpace repeats the history of the internet. Just look at the huge number of practically unreadable webpages with different size fonts and different colours, terribly innappropriate background images. Oh, and a load of commercial interests trying to stuff things down our throats. Loads of chicks though... ;)
So true. Don't go away mad kids, just go away
If /. sucks so much, why are you still here?
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Well, having over 1 million foes is also an achievement ...
The Tao of math: The numbers you can count are not the real numbers.
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.
The Braying and Neighing of Barnyard Animals Follows.
Not just that. I don't know about others, but I read slashdot primarily for discussions, not raw news. There is a lot of places to flood you with news, but much less where you can actually read coherent discussions on the subject. Yes, slashdot's moderation system is far from ideal, but there actually _are_ insightful and interesting comments to read, not just "OMG LOL" babble.
1. Embedded music videos. Anyone have a host list of the music video providers? I'd like to resolve them to 127.0.0.1
2. Bogus accounts. There is a huge rash of "stripper" accounts, consisting of minimal user info, that messages out to single guys to get them to email them at their yahoo accounts. They typically have 4 or 5 risque pictures, making everyone think all women are whores. Bad bad bad.
3. Myspace needs a "safe mode" where the excessively bad(bells and whistles) profiles that sodomize any web browser can be avoided.
4. Why does clicking to one of your groups have to open in a new window? WHY? The top-bar navigation makes that un-neccessary.
But still, myspace is better than orkut. People actually use myspace.
That's not the right attitude. The problem lies with web browsers that accept non-standard code.
Malicious code comes in two flavours - code that is outright malicious, and code that is completely benign in browsers that conform to the W3C specifications, but is interpreted wrongly by some browsers to generate a malicious effect.
The first type is easy to filter out, because you can go to the spec and see how things are meant to be interpreted, and from that determine what should be filtered out. The other type, though, is much harder to filter out, as you also need to be aware of all the little quirks and foibles of all browsers likely to be used to access your web application - something that isn't written down anywhere most of the time.
For example, you might have written code that strips out HTML tags. That's fine, except some versions of Netscape Navigator 4.x treat entirely different Unicode characters as if they were < and >. As a web developer, you have no way of knowing about this unless you are privy to some of the most obscure browser trivia in the world, so unless you take a default deny policy and outlaw any non-ASCII characters (goodbye international visitors), you are likely to write code that is vulnerable to this attack - for Netscape 4 users.
Now multiply that problem by all browsers in use today, and all the little quirks and deviations from spec. that they have, and you'll start to get an idea of why it's not feasible for web developers to be responsible for this problem, and why the responsibility lies at the browser developers' feet.
Bogtha Bogtha Bogtha
- Defining "badness" instead of "goodness"
- 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
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.
This is a great comment, however I quietly lament that the number of people that will understand this is rapidally diminishing..
By the very nature of being a news aggregator, it will never be the first place that a story appears. It will always be elsewhere on the net first, and someone will then notice it and submit it here. So ok, maybe you saw it somewhere else first. Maybe you got it from the original source. Good for you. Those who failed to happen upon the story elsewhere can still learn about it here, and even if you saw it someplace else first, you can still join in the discussion.
This guy used the tag to insert the javascript which slashdot also allows. Not that I'm wanting anyone to do something evil with it but I'm wondering could slashdot be susceptable to the same flaw they're reporting?
You don't ssh to port 80 to read a web page. dolt.
[This space for rent]
After patching to fix this problem, MySpace now becomes the most immune to these types of attacks. Their software is more resistant, their team is more educated. To mix punchlines, pioneers get the arrows, but blows that do not break the back, strengthen it.
--
make install -not war
We're talking about free-form content.
No, we're not. We're talking about HTML, or things that end up as HTML. (For instance, Wiki formatting, UBB formatting, etc.) It's not English text that spread like a virus, it's code.
If you can't figure out how to write something that identifies good HTML, then you absolutely, positively should not be writing code for the web. If you think HTML is "free-form content", you're part of the problem.
The "badness" you are trying to prevent is distinguishable from the "goodness" only by the patterns that it occurs in.
No shit. You are aware that there are decades of work in computer science on the topic? And that the relevant work is all nicely packaged up as libraries that don't even require to really understand said decades of work?
All you have to do is hook up an HTML parser, and reject the content the instant you see anything bad; tags not in the approved list, attributes not in the approved list, etc. For extra bonus points to defend against a bad parser you might consider re-outputting the HTML from the parse tree via your own code that can be guaranteed to only produce safe, code-free HTML by construction, but that's generally unnecessary because for someone who actually knows what they're doing an HTML parser is not that hard, and the crappy/buggy ones generally stay very safely un-famous. (An HTML parser that gracefully handles the shitty HTML on the web today is quite a different story, but that doesn't apply here; you shouldn't be using such a thing for verification.)
If you truly find this hard, you need to either grow your skills until it isn't, stop programming for the web, or batten down the hatches and prepare for the day when something crappy like this happens to your site. The same extends to anytime user input may be interpreted as code that affects anyone else, too. I'm not the one presenting you with these choices; I'm just explaining the situation. It's just that this is how it works, in the real world. "But it's hard!" doesn't change anything.
I'd consider telnetting to any port dangerous, imagine what could happen if the server started sending terminal control sequences.
When you have to write a script to get friends...
Not links, any javascript dialog has an extra button "kill script". I wish the supposedly more featureful alternatives would adopt this simple improvement.
I am trolling