Cross-Site Scripting Worm Floods MySpace 321
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."
XSS? (Score:5, Informative)
XMLHTTP has a same-site policy... the problem here is they let users render html & javascript in their own pages on the site. If slashdot allowed executable javascript in the comments, we'd have the same problem.
Re:XSS? (Score:5, Informative)
Re:XSS? (Score:3, Informative)
"he split the word 'JavaScript' into two lines", and "MySpace has stripped out JavaScript and <script> tags for at least a year and a half"
IE is too forgiving (Score:5, Insightful)
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.
Re:IE is too forgiving (Score:2)
You seem to have been meaning to write '': just out of curiosity, did you deliberately omit the semicolon in the HTML entity for 'less than'? I ask because that (omitting the
No irony was intended (Score:5, Funny)
Re:No irony was intended (Score:5, Funny)
Blame Heisenberg. At any given time every key is either pressed or not until you hit "submit" and find out for sure.
Re:No irony was intended (Score:2, Insightful)
Re:No irony was intended (Score:5, Funny)
I have Schroedinger's wavefunction equation tattooed on my arm, and every time someone asks about it, I explain about the cat and the two-slit experiment. It would probably be more effective if I printed out pamphlets, because there isn't enough time to even explain the cat properly if a grocery-store clerk asks.
Re:No irony was intended (Score:5, Funny)
Heisenberg? Wouldn't that be Schrodinger?
Heisenburg just says that you can never really be sure where the keys actually are, or your fingers for that matter.
Re:IE is too forgiving (Score:5, Insightful)
pseudo-c code:
if (tagname == "style" && tagtype == "text/css") {
} else if (tagname == "style") {
}
But hopefully something less obvious that doesn't scream security flaw.
Re:IE is too forgiving (Score:3, Interesting)
I once made a comment in the Firefox forums about the difference between the way IE and Firefox interpret web pages. IE believes that everyone is an idiot and will pat the designer on the head and fix the errors without telling you what you did wrong.
Re:IE is too forgiving (Score:3, Interesting)
http://www.w3.org/TR/REC-html40/struct/objects.htm l#h-13.2 [w3.org]
Notice "Start tag: required, End tag: forbidden"
Which is pretty unambiguous.
That sites response to letting them know that they were putting out "Forbidden" tags was to come up with a "Compatiability Matrix" for which browsers and vesions of browsers would work with there site.
This is unfortunately the attitude of many sites an
Put them out of work, or give them better skills (Score:2)
D'oh! (Score:2)
Well, yeah. Um, about that. You see, well, it oughta. It just oughta.
But seriously, I think there are other examples where IE does allow incorrect HTML, but now my credibility is just shot. :P
That's Irrevellant (Score:2)
Re:That's Irrevellant (Score:4, Insightful)
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.
Re:That's Irrevellant (Score:4, Informative)
Re:That's Irrevellant (Score:3, Interesting)
Users want browsers that will render their webpages, including pages they author themselves. Because the average person is not capable of writing a web page that parses, and many tools for writing web pages generate invalid HTML, any standards-compliant browser will not render most of the web. Try running your own web pages through SP using any W3C HTML DTD and see what I mean.
The situation is an artefact left over like a minefield from the browser war i
LiveJournal Took up the Responsibility (Score:5, Informative)
I completely agree that IE is the problem, but to say that this is something site administrators couldn't have been prepared for is untrue. To expect a self replicating javascript? No way. But to secure the filter to prevent multiline tags? Yes, cleanhtml.pl already does. It's known and out there already.
Re:That's Irrevellant (Score:3, Funny)
How else could they block Javascript without eliminating the ability to post bits of code or psuedo-code for artistic or informational reasons? Even then it could p
Re:That's Irrevellant (Score:3, Funny)
j-a-v-a-s-c-r-i-p-t, with each character on a new line. It'd be pretty hard for a filter to catch something like that, though I suppose they could strip out newlines and whitespace as well and just look for character sequences.
What a pain in the butt though. Seems like M$ could just produce a browser that doesn't go out of its way to screw itself.
Re:XSS? (Score:2)
http://blog.outer-court.com/archive/2005-10-13-n7
From the perspective of XMLHttpRequest you cannot call a domain that is not the original HTML page. IE, Mozilla, and Safari implement same domain policy and having experimented it is not possible.
Re:XSS? (Score:5, Informative)
From what I gather, you can upload CSS tags and other non-harmful tags. However, 'Samy' managed to find out that instead of writing valid CSS code inside the CSS tag, you can simply write a Script tag (so long as you split it over two lines) and upload it that way.
This in itself shouldn't be a problem; since the code is inside a CSS tag it should be parsed as invalid CSS code, and so there's no reason for MySpace to have blocked it.
This is where IE comes into it, if you are using IE, IE will parse it as a valid Javascript tag anyway, and execute the code.
This isn't really a bug in MySpace (well, technically it is now), it's more like a bug in IE which can be exploited on MySpace, or any other site which allows similar tags in which code can be 'hidden'.
Re:XSS? (Score:3, Informative)
Re:XSS? (Score:5, Funny)
Given its userbase, if Slashdot allowed this, it would have far far far worse problems. Like "if you ever read the wrong Slashdot comment with Internet Explorer, you'll leave a goatse picture on every ASP and Cold Fusion website you visit thereafter..."
Re:XSS? (Score:5, Funny)
AJAX vuns (Score:3, Insightful)
Re:AJAX vuns (Score:2)
Re:AJAX vuns (Score:3, Informative)
Re:AJAX vuns (Score:3, Insightful)
Re:AJAX vuns (Score:2)
In this case it's a problem with IE for improperly running JavaScript where it shouldn't. Or you could argue it's MySpace's fault for not knowing
Re:AJAX vuns (Score:3, Informative)
XmlHttpRequest breaks the ingrained UI idiom of 'nothing happens until I click something'. Ajax (specifically XmlHttpRequest) has some scary implications for phishing. From a post on JoelOnSoftware discussion list by 'JD'
For example, when someone clicks a link in an email that is out phishing for an SSN and personal info, you could be half-way through the form, and think - wait, I don't want to do this. BUT, with XmlHttpRequest, your information that you've only typed into the form has already been nab
Aww... (Score:5, Funny)
Re:Aww... (Score:5, Funny)
Re:Aww... (Score:5, Insightful)
Look on the bright side! (Score:3, Funny)
No kidding. But look on the bright side -- he has dramatically increased his chances of having at least one *very* close, long-term friend. Bubba, meet your new cellmail, "Samy."
I find this amusing... (Score:5, Interesting)
So this guy found a way to win the popularity contest. I scoff at him too, though at the same time I must laud him for his creativity. If other
Comment removed (Score:4, Interesting)
Re:I find this amusing... (Score:3, Interesting)
Oh and % is used in LIKE queries, that may be why its filtered?
Jeremy
Re:I find this amusing... (Score:3, Informative)
The term cross site scripting is not a very accurate description of this class of vulnerability. In the words of XSS pioneer Marc Slemko:
Check out the full article for a good descri
Re:I find this amusing... (Score:2)
Nearly as amusing is this common typo for "/.ers". I hypothesize that Linux users are most prone, since typing "./" on the command line means "here" in the directory sense.
OT as all get out, of course.
Re:I find this amusing... (Score:2)
Re:I find this amusing... (Score:2)
Go Samy! (Score:4, Funny)
Re:Go Samy! (Score:2)
I just hope the channel is legal by now.
More info... (Score:5, Informative)
Evidently LiveJournal and other sites take care to scrub out JavaScript in user-provided web pages, but the rumors are that sometimes people do figure out how to obfuscate their HTML enough to deliver the payload, despite the scrubbers.
Re:More info... (Score:2)
kinda reminds me of windows..
Re:More info... (Score:2)
Re:More info... (Score:2, Informative)
Re:More info... (Score:2)
MySpace also scrubs javascript. This guy put obfuscated javascript into CSS for delivery.
Re:More info... (Score:5, Insightful)
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.
Re:More info... (Score:3, Informative)
Rules like this are arbitrary and cause other problems. My passwords use more than just letters, numbers, and underscores. There are lots of other characters that are perfectly valid. If you are going to define what is good, define it universally, not arbitrarily. How about all non-control ASCII characters: 32-126? It is safe but also non-restrict
Re:More info... (Score:4, Insightful)
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.
Back in my day (Score:5, Funny)
And the phrase for self-replicating viruses was... (Score:5, Funny)
Re:And the phrase for self-replicating viruses was (Score:3, Funny)
At my school, I think it was called "herpes".
Woefully inefficient (Score:2)
Re:Back in my day (Score:5, Funny)
Awsome (Score:5, Funny)
Here's the Guys Explanation of his code (Score:5, Informative)
And here [namb.la] is his version of the story.
He comes off as a sweet practical joker. But maybe that's just b.s. that he cooked up after he realized he might have some 'splainin' to do.
Also, his site really is "namb.la" -- he's making some sort of joke at NAMBDLA's expense, which is pretty suspect, I think.
Re:Here's the Guys Explanation of his code (Score:5, Funny)
Re:Here's the Guys Explanation of his code (Score:5, Funny)
LOL No kidding! "Here's the home page of the guy famous for writing viral web code that infects your browswer, wanna go see it?" Golly, sounds like a swell idea, what's the worst that could happen?
With a name like MySpace... (Score:5, Funny)
... it shouldn't be surprising that someone took it literally and tried to claim it all for himself.
EricWilliam Shatner boldly goes like no man has before [ericgiguere.com]
samy is my hero (Score:5, Informative)
In the beginning (Score:3, Insightful)
Re:In the beginning (Score:3, Informative)
myspace is certainly addictive though
Interview with "Samy" (Score:3, Informative)
samy is my hero (Score:5, Informative)
Samy's info on the topic (coral) [nyud.net]
His explanation of how it works [namb.la]
Don't you hate when you forget stuff? (Score:5, Funny)
time to use quoting? (Score:2)
Maybe next time they might want to look here:
http://shiflett.org/articles/foiling-cross-site-a
XSS basics (Score:5, Informative)
The exploit involves placing javascript code into your posting on a website, such that when other people visit the website their browsers download your comment with the embedded javascript, which is then processed. The javascript, because it is being processed on your machine as part of the rendering of the page, can be used to exploit all sorts of vulnerabilities within browsers. When you have browsers tightly coupled with operating systems, this can open up some rather scary scenarios.
In this case, the guy just used the vulnerability to make some relatively benign changes, but he could have just as easily exploited some of the many problems with IE to be more malicious.
XMLHttpRequest (Score:2)
Re:XMLHttpRequest (Score:4, Informative)
Obligatory... (Score:3, Funny)
The Code (Score:2, Informative)
Unpatched security holes? (Score:3, Funny)
STD (Score:2)
Quick and Dirty solution (Score:2, Interesting)
<script type="text/javascript">
for (i = 0; i < 1000; ++i) {
alert("Disable JavaScript for this site!");
};
alert("OK
</script>
Now you can be sure that {almost*} nobody visiting your site has JavaScript enabled, so there is no chance of this affecting them.
* There probably is _somebody_ _somewhere_ who really is masochistic enough t
Re:Quick and Dirty solution (Score:2)
If you find a corresponding browser vulnerability, you just might switch off JavaScript with your JavaScript code, of course
Re:Quick and Dirty solution (Score:5, Interesting)
while (1) {alert("nope!");} Will DOS any browser in use today. You'll have to kill it via some OS level functionality, because alerts are modal and prevent interaction with the browser chrome. I understand that the JS spec is based on "run to completion", but is there any reason why JS alerts (and confirms, etc) shouldn't be model to the document canvas (disabling interaction with the canvas, but not browser chrome) rather than the browser itself?
Re:Quick and Dirty solution (Score:3, Insightful)
Not links, any javascript dialog has an extra button "kill script". I wish the supposedly more featureful alternatives would adopt this simple improvement.
With myspace popularity, comes the problems (Score:3, Insightful)
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.
Re:With myspace popularity, comes the problems (Score:3, Interesting)
Which is why I now have in my Apache configuration.
For further reading (Score:2)
the turd of myspace (Score:2, Informative)
All I can surmise is that the person who designed this worm is far more clever than any of the people who designed MySpace.
I still don't have a profile on it...
Not the first worm of that type (Score:3, Interesting)
Advogato (mod_virgule) was vulnerable to this sort of thing before (back in 2002). Won't be surprised if there were others too.
Anyway, I've proposed years ago that there be HTML tags to turn off any active/dynamic stuff.
Currently the HTML situation is like only being able to turn off the lights by going to dozens of switches one by one and turning them off. There is no main power switch to turn ALL the lights off, or even groups of lights off.
I guess it's just me who thinks that the HTML equivalent of a "Big Red OFF" switch would be useful.
e.g.
<shieldson lock="randomstring" allowed="keyword,keyword,keyword"
disallowed material disabled
<shieldsoff lock="randomstring"/>
state restored to before lock
Where keywords:
textonly = just text
basic = basic formatting <em> <b> <i> <strong>
tables = tables
urls= plain <a href=""> no javascript etc
images= plain images, no javascript etc.
java=java
javascript=javascript.
The idea is it will be very hard for the attacker to guess the random string.
Oh well...
About (2?) years ago (Score:5, Interesting)
Mine propagated faster than this one because it didn't rely on profile views. Anytime you saw the name, whether it be in a comment, profile, or search, you would be infected. However, with the script executing 100 times per page view, myspace's servers quickly became overloaded and crashed (I didn't really expect it to work). I also essentially staged a DDoS attack against my web server which was hosting the script (it needed to be hosted in order to fit in the 'name' field).
Another note: myspace never removed the scripts that were saved before they outlawed javascript. To this day, I can read a user's inbox and sent messages when they view my profile. I also was going to write a DHTML roleplaying game that ran on myspace, but they locked that account because of the virus. It still plays music and lets you manipulate your inventory though =D
Just a question... (Score:3, Insightful)
Evolution in Action (Score:3, Insightful)
How he did it (Score:4, Informative)
http://namb.la/popular/tech.html [namb.la]
Re:Day late, dollar short. (Score:5, Insightful)
Re:Day late, dollar short. (Score:2, Insightful)
Re:Day late, dollar short. (Score:3, Insightful)
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
Re:Day late, dollar short. (Score:2)
Re:Day late, dollar short. (Score:4, Insightful)
Re:Day late, dollar short. (Score:2, Funny)
Re:Day late, dollar short. (Score:2)
For the chicks, duh...
Re:Day late, dollar short. (Score:2)
Re:Well, people have been saying it's a security r (Score:5, Insightful)