No, we just improved it. That’s how code evolves. Giving up is lame.
Please share the code.
Firefox has a bug and cookies are still dangerous. What else is new?
When will somebody break down and fix the Internet (create a new one)? Probably when somebody breaks down and creates a new engine that is better than gasoline.
The ideas and the resources are there, but how can you change something billions of people are already benefitting from?
It’s an excellent idea, and provides a bit of secondary protection if you’re not confident you’ve eliminated all the XSS vulnerabilities. But unfortunately the XHR workaround you provided renders it completely worthless.
It’s always nice to hear about obscure things like that (especially when written so eloquently), but that’s not a useful security measure. Even the 10 minutes it would take to implement it would be better spent checking your code for potential problems.
So, where’s the post on what exactly was wrong with the html sanitizer and how exactly you fixed it? Or is that too narrow focus for the blog. 
@bex you just screwed anyone who sits behind a proxy server. IP alone isn’t enough, and your web server is too high a layer to be effective at spotting all the ways to spoof.
With a site like SO, it’s going to be far more difficult to build a sanitizer, because there will be legitimate content, etc, that has script blah tags. That in itself is a reason to create your own markup syntax (or borrow wiki’s) because that way it’s easier to verify and reject content without losing sight of the trees for the forest.
With normal punter content, I strip anything remotely looking like markup because it’s not in the spec. Also most users want to use angle brackets in their normal sense, so a dead simple catch-anything is just encode all angle brackets and ampersands and store it that way. . Spec changes and they want links, allow it via something like BBCode , my sanitizer doesn’t need to change, and I can validate/display only what I want to allow.
I still say that HTML/XML creators made one of the biggest WTF’s by reuse of ultra-common symbols as the basis for the one format to rule them all.
As a final point, it’s really hard when you have a small team trying to thwart a legion of bored 16 year old’s. In some ways it’s good, because DRM will never succeed because of them, in other ways it sucks when you’re trying to figure out what some little script kiddie did to deface your site.
@omalley
Also most users want to use angle brackets in their normal sense, so a dead simple catch-anything is just encode all angle brackets and ampersands and store it that way.
If you’re also creating your final HTML files when you store it then OK. Otherwise you’re doing this the wrong way around. Read my comments above, as well as others’.
You want to escape for HTML only when the data is being put into a HTML document.
Similarly, you want to escape for SQL when the data is being put into an SQL query.
In normal circumstances, you don’t STORE the escaped data.
I’m not sure he understood the implications, as he was quick to dismiss it as slowing down the average script kiddie for 15 seconds.
He was right. Instead of stealing document.cookie, xss.js could have set up a proxy/shell/tunnel allowing the attacker to take advantage of your friend’s site using his own browser.
@correct, it all depends, and I don’t see the problem with storing escaped data. It’s a space tradeoff I’m willing to make, but where I feel the penalty for failure is less severe. I’m pessimistic and nowhere near perfect, so I will forget now and again despite best efforts.
If you don’t allow unsafe characters, then just completely remove them from input. Done
If you do allow unsafe characters, there are two scenario’s
- you store user input verbatim, and you always remember to escape when displaying output, and you hope input cleaning works 100%.
- you store user input escaped, and you need to remember to unescape when your user is editing.
Penalty for failing in (1) - where you forget to escape, you expose your users to xss, etc.
Penalty for failing in (2) - editable has your escaped content lt; gt; amp; etc. - looks stupid, but still safe.
Performance penalty in (1) is continual escaping on every view.
Performance penalty in (2) is only escaping / unescaping when edited.
(2) isn’t perfect, but I’ll take the hit, trusting the team to get the few edit scenarios correct versus the 100’s of view scenario’s correct. I call it err’ing on the side of caution.
Is there something I’ve overlooked? What is your objection to storing escaped data?
Restricting your cookie based on IP address is a bad idea; for two reasons:
An IP address can potentially have a LOT of users behind it, through NAT and the likes. There’s even a few ISPs that I’ve known to do this.
And secondly, your site breaks horribly for users behind load balancing proxies (larger organisations, or even the tor anonymising proxy).
Anyone remember when Yahoo! messenger used to allow javascript (through IE i guess)? I used to type simple little bits like instant unlimited new windows or alerts to mess with my friends… thinking back on that, that’s just scary!
On the same subject from a J2EE perspective
http://gustlik.wordpress.com/2008/06/20/cross-site-scripting-and-httponly-attribute/
Well done Jeff. XSS, yeah, yeah, yeah. Not my site. HA. Just found a hole and implemented httpOnly. Thanks for this reminded!
so, basically, HttpOnly-cookies protect you from your specific exploit and force the attacker to just redirect the users to a fake login on a page he controls or something similar.
If you allow arbitrary javascript on your site, its not your site anymore. HttpOnly-cooke does not change that.
Live and learn. I made a simple comment system for a website and it basically just removes every character that could be used in a script attack when the data is posted back to the page. Essentially it doesn’t let you use any HTML or other fancy stuff in the comment area so it’s a bit limited in what you can display for a comment, but at the same time it’s generally pretty secure (crosses fingers) and while comment spam happens at times whatever links are posted aren’t ever active.
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.
scriptalert(‘hello XSS!’);/script
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:
http://www.codinghorror.com/blog/archives/001116.html
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.
No, we just improved it. That’s how code evolves. Giving up is lame.
Giving up on idiotic idea is generally considered wise.