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?

A hole is a hole

[Watson Ladd]

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.

User Content

[agnokapathetic]

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 <scr\x00ipt></s\x00cript> as valid code. Even when filters are put into place, all it takes is one XSS virus [bindshell.net] 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 [cgisecurity.com] 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 [parish.ath.cx]

Crazy

[Bogtha]

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

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 is of the utmost importance to note that a page that has an "XSS vulnerablity" is no more dangerous than visiting a random result generated by a Google search

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.

XSS - a bug... sometimes

[madsheep]

I think someone would be pretty hard pressed to convince me that XSS cannot be considered the earmark of bad or insecure coding in all or most cases. If anyone reads full disclosure we all know that any given moron can spend 24 hours a day looking on every website to find some XSS bug in the page. Now just because XSS exists in a site does not make it insecure or poorly coded (the later is arguable). However, when these XSS bugs exist on websites that use session cookies or have a login of some sort that allows users to take actions, post, edit things, etc. then it is a product of insecure and poor coding. The risks exists when something can be gained by a threat source by conducting an XSS attack. If a user can post something on slashdot that slaps over my slashdot username and password or my session cookie (allowing them to jump in on slashdot right now and post as me) then it is a security risk. Finding a XSS issue on a webpage such as one that www.arin.net (see Full Disclosure) really doesn't do anything or represent a risk. It is more about what can be gained or done from the XSS attack. As a quick side not to this dicussion.. XSS is *VERY* easy to prevent. Much more so than SQL injection. Who knows maybe these people will try and reclassify SQL injection as not being a problem either. Sanitizing user input by not allowing it or for example converting to < and > respectively is pretty easy and will stop almost all of these attacks. There is no excuse for not being able to secure a page with such coding practices to protect your site and users.

First language

[ptaff]

Are they unavoidable, or just a symptom of lazy coding, or both?

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 [develix.com]) 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.

They are flat wrong

[Snowhare]

XSS is not unavoidable and it is a security vulnerability. Slashdot has a cookie based login system. This means that if there is an XSS vulnerability in Slashdot I can cause any action a logged in user (maybe, Commander Taco?) can cause by doing something as simple as tricking them into loading a web page with an 'invisible' 1 pixel tall frame exploiting the XSS. Saying XSS isn't a security vulnerability is like claiming that leaving your house keys under the doormat isn't a security vulnerability.

XSS has always been bullshit

[neuroxmurf]

If you allow local execution of code provided by untrusted remote sites, you have no security and never have, no matter how much the vendor assures you their "sandbox" is safe. XSS is not the security hole, it's just the latest batch of holes in the entire concept of client-side scripting.

Can't understand

[Vexorian]

Bulletin Boards have been effective against these issues for ages with bbcodes that use [] instead of > < . Also wikipedia has excellent formatting features without letting users ever use an html tag by themselves.

By simply turning >< into &gt;&lt;before displaying content that was influenced by user input you get rid of every single XSS risk. If users complaint about it being too limited they should get their own site instead of depenging on blog/forum/ whatever other thing.

Huh?

[GT_Alias]

Buffer overflows are an unescapable symptom, C is the real problem. Car accidents aren't the problem...steering wheels are.

Maybe the people writing web apps need better training? No matter how safe you make the language, there will be people using it who are inexperienced, unfamiliar, or otherwise uneducated about the nuances of paranoid programming. It's very narrow-sighted to blame the tool.

Most at risk

[Joebert]

Advertisers are the ones who are effected the worst by this.

Banks & things like that are insured against loss, Federally in the case of banks.
Advertisers who pay for people to click things on the other hand, are not.

I'd bet CowboyNeals left nut there's thousands of dollars a day being scammed from advertisers through the use of XSS clicking adverts in the background, or changing the target address of an add banner.

Complete Twit

[Anonymous Coward]

Read some of the other guy's articles, he's a complete twit. The best is the one on how javascript should be dead and replaced with VBScript, and how Firefox is "against" Javascript, and how javascript was "almost dead" until Gmail came around.

Probably a 15 year old kid. Its a fucking wordpress site w/ the default theme. I mean, come on, seriously.

Re:This guy doesn't know what he is talking about!

[jrumney]

I don't feel particulay sorry for fools who fall for phishing scams

I sure wouldn't want to bank with a company that called its customers fools when the phishing scam was being run from the bank's own website.

Re:Don't allow the GET method except for index...

[kobaz]

POST is not secure in any way. POST is jsut another method of sending data to the web server, anyone can send the server any data they please to try and exploit your app. The key is validating all user input so that something unexpected never gets into your backend.