LOL it’s so funny how you take any opportunity possible to show that Microsoft’s software is better than the alternatives.
Once again an example, that shows that you should never (ever!) use cookies to secure a site
Neat-o… does Rails have an automated script to test all the known XSS attacks on ha.ckers.com?
I wouldn’t be surprised if one or two slipped by…
I’m a fan of HttpOnly
http://www.guidanceshare.com/wiki/ASP.NET_1.1_Security_Guidelines_-_Cross-Site_Scripting
Several questions have come up
Why was HttpOnly implemented by Microsoft on IE6 first
Why is HttpOnly broken on Firefox
Why is it not on all browsers
Why is it not on as standard
All of these have one answer - it is a patch to fix a symptom of bad coding and not a solution
It fixes (or partly fixes) one security hole out of a huge number, it is not a universal fix …
You should sanitize properly everything from the user or you will have a security problem …
I’d like to seek someone crack my PHP HTML sanitizer …
Google for htmlspecialchars vulnerability…
@correct you missed the point entirely and I have a hard time believing that you read what I had to say. Then again I think your comments been sanitized because I find your latest response barely intelligible. Command-line escaping? wtf?
@bex and others, you can’t, from today’s web servers, have enough information to detect all spoofed attacks, even with encrypted cookies. Buy a good stateful router/firewall, that’s my only point.
Also, you don’t just need to worry about XSS. You also need to worry about anything else in between you and a web site that steals cookies. If your friend next to you can steal your cookie, he can ‘replay’ an action and pretend to be you.
Also, can anyone explain why the ajax double-cookie is any sort of remedy? Maybe I’m just thick, but I don’t why it’s a silver bullet.
Also, if you only send authentication cookies over https, and never in plaintext, would xss exploits be able to steal them?
Why the insistence that IE7 is less broken than Firefox in regards to HttpOnly? I see the same bug in both at http://ha.ckers.org/httponly.cgi
Already pointed out but just to show more practical way to bypass HTTPOnly cookies take a look at XSS Tunelling - http://labs.portcullis.co.uk/application/xss-tunnelling/xss-tunnel/
Basically it’s a defense in depth approach and quite cheap to implement but obviously not the silver bullet.
Re: validating IP - as others have mentioned, the assumption that changed IP == attempted hack will run into false-positive problems on users from some banks (and perhaps other large companies / AOL users / whatever, but I’m sure about the banks). It’s unfortunate.
Wouldn’t…
XMLHttpRequest.prototype.__defineGetter__('getAllResponseHeaders', function(){ });
be a good workaround for Firefox’s issue?
Now they’ll have to copy the html of the login screen with the expired session message and have their javascript output that instead of stealing the cookies.
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. 
It’s a difficult scenario, because you can’t just clobber every questionable thing that comes over the wire from the user.
You do.
@Jonah hits it on the head. There’s always a way to hijack a session, even if it’s walking up to an unattended computer. Any critical / costly action should require the user to retype their password (or some secondary authentication method).
At least HttpOnly can try to limit what browser scripts can do, and it’s a step in the right direction, but as others point out, it’s not yet a total fix.
Another fix I can think of would be if running script couldn’t load other scripts on the fly (ie via eval), and your web framework would inspect every pages output and remove any scripts references / and perhaps even not allow inline scripts, you could be a lot safer.
Unfortunately there are a lot of vectors of attack, and it’s currently very easy for a developer to screw up.
@ Jonah, I think you’re right - when making profile changes etc a password should always be required. Good point indeed.
I’m looking at implementing commenting etc on my site (its a blog, but I don’t care too much about the parsing of the blog entries since I’m the only one making them). I was wondering where the author stated that you can’t clobber every questionable thing that comes through - Why not? I was thinking of just parsing all angle brackets to their entity codes and then running through the script to look for acceptable tags, but instead of looking at tag letters between and brackets, I’d look at letters between entity codes.
Is there anything glaringly wrong with this approach? Script stuff wouldn’t get through because I would only allow specific tags such as strong, em, u, strike etc.
@bex: B, I, UL, OL, LI, PRE, CODE, STRIKE, and BLOCKQUOTE
If you expect your users to want BLOCKQUOTE, UL, and OL, you should probably be using a smarter text markup language (MediaWiki-esque) in the first place. ISTR Jeff was considering this route for stackoverflow a while back, but rejected it.
My list of HTML tags needed in this blog comment section: P, B, I, S (and possibly STRIKE), (might as well throw in U for completeness), TT (or CODE), PRE, A HREF (with obviously well-formed URLs only). A NAME is too abusable. SMALL might be nice, but it’s abusable. BIG is too abusable.
RE Another fix and remove any scripts references I neglected to say the web framework would remove any script references that you didn’t explicitly allow, which outside of DNS poisoning would pretty much nail the coffin around many XSS.
Then again, it’s all a giant band-aid as everything is sent plain-text. It takes only 1 compromised router…
It’s actually not that complicated. URL encode everything. so for example b becomes lt;b/gt;, etc… then selectively use text substitution to reenable what you want, i.e. ‘lt;bgt;’ = 'b’
Everything else remains escaped
Tony
There seems to be a huge emphasis on cookie stealing, but don’t forget that XMLHttpObject is extremely dangerous since it can mimic any user action! What if an XSS script loads the user profile form, changes the email address, and then requests a new password be sent to it (via the common Forgot password form)? The account is hijacked without even touching a cookie. Place additional security around these sensitive areas and do not rely solely on the HttpOnly directive.