Giving up is lame? Well, I don’t want to be lame! So there’s no way I’ll give up on my reimplementation of the OS, compiler, web browser, and I won’t even consider giving up on the rewrite of everything I’ve ever done!
Also, giving up is lame is the worst excuse I’ve ever heard for the not invented here syndrom. Noone said software is a crime against humanity - but it’s actualy not always necessary or appropriate to write everything from scratch.
Most of the time when you accept input from the user the very first thing you do is pass it through a HTML encoder.
I don’t know if you worded this poorly or if this is actually what you’re doing. But that’s not the first thing you do when you accept input. It’s the last thing you do before you output said input to a HTML page.
If you wrote this blog software that way then that’s probably why Andy’s link is garbled up above.
There’s no way that the above input would pass my Regex filters, which obviously contains /?script. Be sure to check for octal syntax as well, because that’s much harder but equally valid.
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.
@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.
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?
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!