Unfortunately, as for any other browser-specific features or those being too recent, we might as well acknowledge that httponly for a second a then, completely forget about it because it’s totally useless … the usual web development nightmare : we’re stuck to the narrowest common set of features
Okay, HttpOnly is an easy temporary fix, but we all know where such tempting temp fix lead us, right ? I’m sure we all agree here it’s not a substitute for sanitizing, but guess what happens in the real world …
If you’re allowing people to use the image tag to link to untrusted URLs, you are already OWNED.
For starters it allows a malcontent to cause people’s browsers to GET any arbitrary URL, fucking with non-idempotent websites, doing DDOS, whatever.
On top of that, for both IE and Opera, if they GET an URL in an img tag, and find it to be javascript, THEY EXECUTE IT. The script tag was totally unnecessary in that hack for targeting IE and Opera.
Jeff, what sites did you use to guide you through making StackOverflow XSS resistant?
I am about to embark on a side project and would like to make the site XSS hardy.
Assume the IP address changes. This means either malice, or a ISP with a rotating pool of proxy IP addresses. Either way, you need something stronger to fix this.
You should re-challenge for non-password information (secondary password, favorite color, SSN, phone call, whatever). Then walk them through secondary authorization with SSL certificates… like myopenid does.
And if the requirements of your application include the
ability to accept such input… then what do you suggest?
I just love how programmers think that they get the final
say when it comes to functional requirements.
You love odd things… and I already took that into account. Read this article about what Jeff is doing, and you’ll see my proposal fits in fine with the functional requirements:
Offhand… I can think of no good reason why a non-trusted user should be allowed to use more than 5-10 safe HTML tags. If I’m wrong, I’d like to see what you think the requirements are.
@bex: Offhand… I can think of no good reason why a non-trusted user should be allowed to use more than 5-10 safe HTML tags. If I’m wrong, I’d like to see what you think the requirements are.
Name them. I will bet you a contrite apology that someone will add an 11th that they’d want within 5 minutes.
HttpOnly should be the default. Making security easily accessible (instead of an obscure feature, as one of the commenters called it) and secure behaviour the default is an essential part of security-aware applications.
But as is typical with IE, providing safe defaults would need some sites to update their code, so unsafe is default, and no one updates their code to add safety. (Why should they? It still works, doesn’t it?)
As for sanitising input: Since input data is supposed to be a structured markup, I agree with other commenters that the very first thing should be to parse it with a fault-tolerant parser (not a HTML encoder as someone else suggested) in order to get a syntactically valid canonical representation. This alone already thwarts lots of tricks, and filtering is so much more robust on a DOM tree than on some text blob. Not easier, but no one said security was easy.
And such a DOM tree nicely serializes to something which has all img src=… attribute values quoted etc., at least if your DOM implementation is worth it’s salt. (I recommend libxml, bindings available for practically every language)
What I do not understand is why the browser is rendering that invalid HTML block.
Also the web application should validate the input and check if it’s valid HTML/XHTML and uses only the allowed tags and attributes. Moe and others seem to be thinking of the same thing.
as mentioned before the sanitiser is clearly written badly. I’d bet its overly complicated in order to fail on this example (something to do with nesting angle brackets? why do you even care how they are nested if you are just encoding them differently?)
further, the cookies are being used naively out of the box. how about encrypting the data you write to them based on the server ip or something similar so that these tricks can’t work?
HttpOnly by default would still be good though… you have to protect the bad programmers from themselves when it comes to anything as accessible as web scripting.
i’m also in favour of storing the data already sanitised. doing it on every output is one of those everything is fast for small n scenarios, and it removes the risk of forgetting to re-sanitise the code somewhere.
Great post, I totally agree about the need to protect cookies.
I’ve been using NeatHtml by Dean Brettle for protection against XSS for quite a while now and I think its the best available solution, though I admit I have not looked closely at the Html Sanitizer, you mentioned.
Another barrier that is frequently used with applications that must accept user-generated HTML is to separate cookie domains: put sensitive pages on a separate origin from the user-generated content. For example, you could have admin.foo.com and comments.foo.com. If sensitive cookies are only setup for domain=admin.foo.com, an XSS on comments.foo.com won’t net anything useful.
Uh, couldn’t someone just filter the response from the server to remove the httpOnly flag? It seems very half-assed to use a feature that is client-side, in SOME browsers. This is a circumstance where it’s important enough to come up with a solution that isn’t just more obfuscated, but that actually has increases the security by an order of magnitude.
My point was less about re-auth in general, but more about trying to detect who had a legitimately rotating IP address. If detected, cookies can’t be trusted… so force the user into an auth scheme that used cookies as secondary to something else. Primary would be SSL Certs or (shudder) Basic Auth over HTTPS.
That’s probably good enough for anonymous comments. These ones are also safe and useful for untrusted comments:
That’s 9 tags. If you want to add a video or an image, you could use a bit of DHTML or Flash to pop up a media selector widget for approved sites: Flickr, YouTube, etc. People get to select URLs to pages, but that’s it. On the back end, check the URL to see if it looks hacked. If so, reject it.
For trusted contributors, you could open it up even more and use tables, headers, links, etc… in which case you’re looking at closer to 20 tags.
For very trusted contributors, you get to use attributes like SRC for IMG, and maybe even SCRIPT nodes.
Of course, @dood mcdoogle summed it up quite well when he said that input filtering cannot ever be sufficient… so you always need an output filtering step. However, there’s no harm in pre-parsing your data and teaching your audience what will and what will not be tolerated.
