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:
http://directwebremoting.org/blog/joe/2007/10/29/web_application_security.html
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! 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.
@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.