Protecting Your Cookies: HttpOnly

For people associating cookies with client IP: Remember that people want to use persistent cookies, and that people have laptops, which get different IPs depends on where they are. Also, some users are behind load-balancing proxies, which may appear to your site as different client IPs.

What should users do to protect themselves?

My knowledge of web design = 0
with that in mind, why the hell that is not the default for every single browser? Why would other people (websites) have to do with cookies from my website?

If there is a reason at all why not make HttpOnly default and create a little thing called NoHttpOnly?

The following is a must-read for all webappers:

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:

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.


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.