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?

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.

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.

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.

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:XSS - a bug... sometimes

[Anonymous Coward]

XSS is *much* harder to prevent than SQL injection. Why? If you're a competent coder, you can secure the code on the server end properly. In order to prevent XSS, you need to know about parsing bugs in the *browser*.

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.

Re:Yes, unavoidable.

[Spazmania]

These websites are designed for distributing content, the same as your bog-standard BBS. People upload content, website displays it. All that is needed to secure it, is to get it to treat code as text, rather than as code. In terms of HTML, that's easy. Just run a regexp on all user-supplied data to convert to >, and the content will be treated as text.

Yeah, I got that. The same argument could have been made about my software: all BBSes could have been programmed to recognize the text escape sequences that would trigger my software and eliminate them. Problem is, they were (as you say) bog-standard BBSes. They weren't expecting to receive any sort of text that some wacky guy's terminal emulator would render as machine code.

Did that make the BBSes insecure? I say baloney. The BBSes weren't the problem. The problem was that my software would accept such text and render it as machine code.

Browsers that run Javascript could be rigged so that some kind of activator has to be present in the main <head> section or no later code will be recognized. They aren't so suddenly its the fault of every individual web form author who doesn't account for the possibility that someone might enter some code in to the form. No way. Put the fault where it belongs: the architecture of the Javascript language.

The Cross Site Scripting Faq

[mrkitty]

Once again if you're curious what XSS is check out

The Cross Site Scripting FAQ [cgisecurity.com]

Re:Can't understand

[Mark Round]

"By simply turning > into ><before displaying content that was influenced by user input you get rid of every single XSS risk"

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

[dk-software-engineer]

That is why you also turn " into &quot; when it's inside double-quotes. This is the right solution, you just have to finetune it. It's not that hard, you just need to remember it every single time it should be done. It's the "remember" stuff that's hard.

Include turning & into &amp;. Finally there's ' (&#039;) and you're done.

Some languages has functions to do this for you [php.net], you just need to call them.

Re:Script tags isn't enough.

[masklinn]

you may want to check Samy's hack of Myspace [namb.la]

While he didn't use it for anything really detrimental, he more than likely could have, especially when you see the bunch of code he managed to cram in.

XSS prevention in web browser?

[IzEBaLL]

In my master thesis I implemented a solution in the mozilla firefox web browser that protects the surfing user. It analyzes the data access and data flow in the JavaScript engine of the web browser.

NoMoXSS (no more XSS)
http://www.seclab.tuwien.ac.at/projects/jstaint/ [tuwien.ac.at]

Although it is only a prototype of an implementation (in a rather old version of firefox), it shows the potential of this solution to stop XSS attacks.

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