Slashdot Mirror
XSS Vulnerabilities Reviewed and Re-Classified
An anonymous reader writes "Security Analysts at NeoSmart Technologies have revisited the now-famous XSS-type security vulnerabilities and attempted to re-classify their status as a security vulnerability. The argument is that XSS vulnerabilities are not a mark of bad or insecure code but rather a nasty but unavoidable risk that's a part of JavaScript - and that even then, XSS 'vulnerable' sites are no less dangerous or vulnerable at heart." Are they unavoidable, or just a symptom of lazy coding, or both?
Samy is still my hero.
Saying that these holes don't matter because websites can't avoid them with the standard method of doing things is just plain wrong from a security standpoint. If you are dealing with sensitive data, secure it. If the standard way won't let you, don't do it the standard way.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
As buzzwordy as Web 2.0 is, end-user content is rapidly becoming the majority of the visible end-user internet experience (e.g. Digg, MySpace, Facebook, etc.) With thousands/millions of users posting content, XSS filters start to become an arms race against the latest techniques. With Internet Explorer even rendering code with as valid code. Even when filters are put into place, all it takes is one XSS virus to take down an entire website.
Even disabling Javascript content all together in websites, with user content, other methods can be used to steal cookies/sessions/user credentials. Flash attacks are becoming more and more common, and are near impossible to protect against. Users demand dynamic user-driven content, the companies comply, I'm just surprised this hasn't been more prevalent.
--Joel
Ajax Translator
Er, no. XSS attacks are caused by sloppy web application developers that fail to encode user-supplied data for output in the appropriate way, and by sloppy web developers that trust that whatever was submitted by a user was submitted by the user intentionally.
Both of these factors have technical solutions that are 100% effective and have been well-known for years. The former has nothing specifically to do with JavaScript anyway, it's just that the holes are most often used to sneak JavaScript onto a page.
This article is a total crock of shit. For instance when it says:
It's no more dangerous in terms of security for the client machine. If Hotmail has a security hole, it doesn't make it more likely that somebody will get onto your computer. But they can still read and delete your email, and send email from your account.
Actually, I take that back, it is more dangerous in terms of security for the client machine. With tools like the NoScript Firefox extension, and the similar mechanisms other browsers have, many people disable JavaScript for the random websites found with Google, but enable them for websites they trust, like Hotmail. So if Hotmail has an XSS vulnerability, they will be executing malicious JavaScript even though they only intended to allow trusted JavaScript to be executed.
This author seems to have no real clue about web security. I guess this is why Slashdot shouldn't link to random weblog entries.
Bogtha Bogtha Bogtha
XSS is not the problem. JavaScript is (just for the record, at NeoSmart we feel JavaScript is more of a headache than it is a life-saver..), and XSS is but a result of the (many) inherent security holes in JavaScript and not in the package itself!
That quote really says it all. The basic argument seems to be very simple: Javascript Sucks, Ergo XSS Vulnerabilities are inevitable. That's about as accurate as saying that if Chewbacca lives on Endor, you must acquit.
As someone who's had to wrangle plenty of Javascript, I agree that it sucks, but I disagree with any argument that security vulnerabilities are inevitable. These days, they seem to be more a product of adding features without thinking about the security implications (Hey, let's allow email viewed in Outlook to run scripts!) than poor implementations of those ideas. Although implementation problems play a part: You're busy coding the nifty new feature, you get to a point where it works, and you happily go and check it into CVS oblivious to the buffer overflow you've introduced.
Fundamentally, there's no such thing as a computer error, only a series of human errors buried deeply enough that they appear to be a computer error (with one exception, that of the expected hardware failure).
I am officially gone from
I wouldn't say lazy, but naive. Lots of people now cut their teeth at programming with HTML/Javascript and a simple server-side scripting language, like PHP or ASP. For a reason unknown, these simple languages (PHP especially) try to create a blanket so thick around the coder that most of them don't even think about validating input.
Crap like auto-string escaping, crap like automagic global variables, crap like easy access to eval(), auto variable casting, these help when learning to program so you can concentrate on the task at hand, but become a big fat no-no when deploying stuff in a networked environment.
Going back to my first programs in BASIC/C/C++, they were probably filled with holes; but for sure they weren't available for the world to hack.
Click on this link for an example against CitiBank
CitiBank Exploit