@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?
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.
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.
@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