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."
The Cross Site Scripting FAQ
Believe me, if I started murdering people, there would be none of you left.
.. XSS links YouTube
my capcha was condom
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.
Before web designers blame themselves for this, the existence of XSS is really a fundamental design flaw in the way JavaScript and browsers work. It should have been obvious as soon as JavaScript came out that these kinds of attacks would become a major issue over time, but the "ooh shiny" attitude of the computer industry meant that people adopted JavaScript without knowing what the implications were. In fact, the other big security hole and productivity drain of the industry, C/C++, got adopted in a similar way.
Writing any substantial piece of software in C, C++, or JavaScript without creating safety or security issues is extremely expensive and beyond the ability or resources of most developers. For C and C++, there are alternatives you can choose today. For JavaScript, you just have to minimize its use or simply not worry about it and let the client fix it with tools like NoScript.
but it's probably pointless. Not enough developers care about their craft.
There's a prominent "popular science" website out there (no, it's not this one that I'm thinking of) that has ENORMOUS XSS vulnerabilities in its image gallery. They pass captions and img src in URL encoded query string parameters. Yuck.
I noticed this about a year ago and reported it to the development team, with a demonstration link that put in a (sorta not nice) image and caption. No response, and when I checked six months ago the vulnerability was still there. So much for being a nice guy.
Bad assumption. If you're assuming everything is coming down correctly encoded you're a fool, all it takes is a bit of javascript that submits to your back end without encoding and *bang*
I'm a web developer and I've said this dozens of times.
VALIDATE ALL INPUT EVERYWHERE.
Validate on the client. (For bandwidth reduction)
Validate at the APP Tier (For security)
Validate at the Data Tier(For security and integrity)
If you accept input from a web page, scrub it, and that doesn't mean stripping brackets or quotes, it means putting in a list of valid characters and tossing or replacing absolutely everything else.
Yes, you might wind up validating something that doesn't need to be validated or scrubbing something that doesn't need to be, the performance hit is worth it.
Also, Stored Procedures are a great resource, if you design them properly you add an extra layer of security that can actually improve your application performance. (All my recent projects have Stored Procedure execute only rights.
If your db code has select * from table in it, you're doing it wrong.
Ok, enough ranting from me.
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.