Slashdot Mirror
Cross-Site Scripting Hits Major Sites
An anonymous reader writes "Dark Reading and SC Magazine covered a story about hackers posting cross-site scripting (XSS) vulnerabilies en mass on dozens of high profile websites including Dell, MSN, HP, Apple, Myspace, YouTube, MSN, Cingular, etc. The media coverage drew the hacker's attention to the publication's websites where they got a taste first-hand. On message board wall-of-shame is PC World, MacWorld, Fox News, the Independent, and ZDNet UK. "...not only did we get the "scoop" on the XSS site problems, but we also got the message loud and clear: Don't assume you're immune to XSS vulnerabilities. They're everywhere." The news comes shortly after Mitre (CVE) released statistics showing XSS has become the most popular exploit. Unfortunately new XSS attacks are growing increasingly severe and scanners are unable to find many of the issues on modern websites."
I particularly like this example.
Here's the spoiler.
Actually, CS 101 is data types and algorithms. Earning my CS degree taught me little of input validation. Most programmers learn security in one of two ways: proactively reading up on it or having one of their applications hacked. Unfortunately I think many average programmers don't consider input validation as much of a priority until after a hole they provided is exploited. When I ask many web developers what they do to prevent SQL injection attacks, for example, only about half have even considered it. Scary.
Developers: We can use your help.
Draw you own conclusions from there...
...quicker, easier, more seductive the darkside is...but more powerful, it is not.
A while ago, someone posted a link to a webpage that, when clicked, caused their post to be moderated up. Their post was at +5 for quite a while until enough replies got moderated up pointing out that the link wasn't what it claimed to be.
So, in a sense, Slashdot has already been hit by a cross-site scripting vulnerability. The fix for XSS vulnerabilities like that involves requiring a secret token to be sent to take user actions, to prevent people from creating forms off-site and submitting them as the user. I suppose checking the referrer may work too, but I wouldn't count on it.
You are in a maze of twisty little relative jumps, all alike.
Maybe I lucked out with a particularly cluefull teacher, but input validation was beaten into me learning Basic on an Apple II(e?) in high school: everyone fails the first round of the Craps game assignment when the teacher asks "what happens when I bet a negative amount?".
I've seen the interesting effects of this first hand with a customers server, which I was tasked to unhack. Took a while to spot the reason the server was hacked because stupidly I didn't think of XSS when I considered the range of hacks that had occurred. When I did finally start grepping the access_logs and saw the rather odd things being passed through an enquiry form script things started to piece together. I've filched a copy of the script passed and its quite impressive, though its probably reasonble to stake a claim on the hacker not being the script writer given the sheer wealth of comments and how to customize tips present. n00bishly (but then I'm not employed to harden boxes, nor am I a website programmer) I didn't expect a site to be quite so vulnerable to such a range of exploitation through XSS. The script I have includes stuff to exploit unpatched mysql to create new users, passes a load of hex strings I won't even hazard a guess at their purpose etc. etc. :)
As a geek I appreciate it the technical qualities, as the guy who had to unhack an exploited server however..
You could probably take a random blob of ones and zeros, run multiple instances of it as an executable image while randomly tweaking bits until you evolved a real executable, far faster than you could analyze some of the code I've had to replace over the years.
Tokens probably solve some of these problem. And something like this doesn't hurt:
http://cyberai.com/inputfilter/index.php
Innovation makes enemies of all those who prospered under the old regime... -- Machiavelli
The problem from what I have seen is in the attitude of the people running the websites. Their attitude tends to be that cross-site scripting doesn't directly impact their servers but only impacts the systems viewing the website. Since this doesn't have a direct impact on their server's it's not a high visibility threat to them. Their attitude towards their visitors is "We are secure but it sucks to be you."
"Anything tastes good if you deep fry it."
Same here; I used to work for a grocery company that allowed customers to upload photos to their image lab for processing. I discovered several XSS vulnerabilities in their interface and pointed them out; a year later, they're all still there. Not only does it leave all of their customer's private photos vulnerable, but someone could leverage the exploit to do all sorts of nasty things, especially since there are ActiveX controls you must install for the site to work...
I say this because people need to be aware that links are not the only vector. My favorite one I've seen so far is <bgsound src='javascript:bad_code()'>. If you choose poorly and are trying to filter out bad tags (instead of what you should be doing, specifying only exactly what tags and attributes are allowed and forbidding anything else that looks like a tag), did you remember to block out the BGSOUND tag? If not, that auto-executes; it doesn't even need to be clicked. (IE may have closed that; I saw this in the IE 4 era.)
As a content manager for the U of Rochester when I was a student there, I witnessed thousands of attempts at XSS every month. All of this thanks to one idiot who decided he wanted to put a mambo website up on the student activities server, we had our main server breached and multiple websites defaced. once you're breached, everyone wants to try to hack you again. One interesting thing I noticed is that the majority of XSS attempts will try to call a script in a file with a .gif or .jpg name. This way, if a curious person sees the attempt and tries to visit the linked script, all they get is a broken image. However, the file_get_contents php function, or other such functions, will read those as PHP. I've seen these scripts uploaded to government websites, university servers and many other places. The one that was put on the U of Rochester server attempted to delete all of the files on the server and put in code for what looked like a perl proxy server (i dunno, it was kinda obfuscated, and I'm not too good at perl yet).
The XSS scripts are quite complex, too. Some of them create HTML/javascript console interfaces for people to interact with the server as if they had an SSH connection.
And they're all over the place. I've got a website that's had less than 1000 hits, and I've seen three separate attempts to use XSS on it.
PayPal had it yesterday. I went there and got a cert pop up. The cert was for ebayobject.com, not www.paypal.com. Needless to say, I ran, and I ran fast.