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.
document.write("It's very hard to check for XSS. I can understand why most people don't bother.")
You know, I've been waiting for this feature on weather.com
The reason most vuln scanners can't find XSS vulns on modern sites is because of the increased amount of JavaScript and Flash (with ActionScript) that's in use. But some scanners can grok this stuff to varying degrees of completeness.
I'm sorry, I really don't grok Cross-Site Scripting issues...
Are there really that many web "programmers" out there that don't check their user-supplied inputs? I mean, that shit is CS 101...
No web developer has written XSS vulnerable code since 2002. What we have is total morons passing themselves off as web developers, just like we have thousands of "web designers" who don't know the meaning of the word "design".
For most contracts, if you aren't paying experienced developers, there should still be money in the budget for a pro to give the code the once over and do a sign-off.
So would it be technically possible at this point to move away from the web application and back to the client server app? Here's a path example:
* Java Client
* Servlet Interface for the client
* Java webstart deployment
* Java plugin on the clients
For this path the questions would surround authenticating the client and the hassle of installing the java plugin.
Rinse and repeat for the obligatory Microsoft solution.
I've never been a fan of web applications and form given the simplicity of creating an SQL injection attack or XSS for that matter. At least if the client application was built for the specific application you expose yourself to less or more obscure security vulnerabilities by nature.
You are checking your backups, aren't you?
.. XSS links YouTube
my capcha was condom
Draw you own conclusions from there...
...quicker, easier, more seductive the darkside is...but more powerful, it is not.
...remains unaffec... FOJSF{09fiE*EU90av['vlwIOA934MAwadpskf[aepfkfa[-09 u9a
GetOuttaMySpace - The Anti-Social Network
Web 1.0: Simple fishing scam
Web 2.0: Cross-Site Scripting
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.
It looks like the attacks can be prevented by simple user input validation. Are the above mentioned high profile website developers/architects being too lazy or nobody knew about this type of vulnerability until recently ? I cant see how Joe Average will know about this exploit because he will not bother to read the query string(or even understand what it does) if it points to major website.
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.
A paper on cross-site tracking is available here, along with two preventative extensions called SafeHistory and SafeCache.
...other interesting privacy tools are...
To help safeguard from scripting attacks, I also use NoScript extension.
The CookieSafe extension will block and help you manage cookies better than Firefox's built-in manager.
Stealther (prevents recording of history and blocks ReferentHeader)
Tor anonymizer + Foxyproxy extension
ImgLikeOpera can switch image prefs with ease
Flashblock (stops flash animations from running until you click them)
and probably much more
Fuck off back to FFC.
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."
Where is the law in these cases?
I'm sure there are ways to know who the hacker is, so why don't they use the information to catch the criminals and put them on trial?
-- You must be yay-high to rule the world.
The biggest problem is farming everything in the world out to $8/hr guys in some foreign country. If you pay $8/hr, you're going to get an $8/hr guy. Keep in mind that Wal-Mart starts at $9/hr. Given these two statements, I fail to see why it's surprising that such simply fixed vulnerabilities continue to plague software.
2 cents,
QueenB
HDGary secures my bank
Which is why I always use SafeHTML whenever my applications ask for input.
____ plex
Now guys, who cares `bout XSS when we have IE 0dayz around...
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.
You can't just post something like this without a link to the post in question.
Please?
Mmmm.. Donuts
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.
Sing with me...
Who stole the cookie from the browser's cache?
Zero Cool stole the cookie from the browser's cache.
Who me?
Yes you!
Couldn't be!...
"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."
Well if it was the goatse.cx guy? Then you blinded them. They're proably laid off collecting disability. While their replacements have been warned not to accept contact with you.
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.
.. or his browser!
Please mod the parent up.
If you're assuming everything is coming down correctly encoded you're a fool. This goes for logins ("admin=true" in the URL? BAD!), data, anything logic-related, etc. Scrub it all. Paranoia is the proper way of life for web developers.
How many "web" templating systems do you know that automatically escape HTML unless told otherwise? I know of one that can be made to do so: Mason. Even then, you have to enable it, as it's not turned on by default.
What about PHP, ASP, JSP and so on? Will they ever grow up and automatically escape HTML by default? I doubt it very much.
In the meantime, there's always mod_security if you're willing to invest the time configuring it. But it's no guarantee...
-Dom
This would seem to imply that for OSS software where the user pays NOTHING and most developers get paid NOTHING, you get ONLY JUNK? Hardly. You often do get what you pay for when you consider relative pay, but not always.
I quite often see people using $PHP_SELF ( or better $_SERVER['PHP_SELF'] ) in their php applications (for example, for the form action on a self posting form). What most of them don't realise is that it is user input, and very easy to inject any content into this.
/> />
l >
I think this is a major XSS vector, because this is unknown (really now, wouldn't you expect a $_SERVER variable to be safe?)
For example:
<form action="<?php echo $_SERVER['PHP_SELF'];?>" method="get">
<input type="text" name="field"
<input type="submit"
</form>
Going to - page.php/"<script>alert('xss');</script> will work quite nicely (note the trailing slash after the page name).
There's a good discussion of it at <URL:http://blog.phpdoc.info/archives/13-guid.htm
henry -- the human evolution news relay
They've been around much longer than this report suggests.
Utube kicks ass!
Hi guys! I am still learning to build a trusted websites for my own used... any recommended sites for me to refer?