Your JavaScript from the remote server is hardly ideal. Here is some better code I developed while researching this security issue. In order to create a deliberately vulnerable ASP.NET page I had to use two page directives: ValidateRequest=false and enableEventValidation=false
Pretty neat solution. But this way, you are restricting the use of the cookie to HTTP. So you can’t use the cookie client side AND via XmlHTTPRequests…
So basically, why does one need a custom cookie? Why not just put the value in the ASP.NET Session? Like this:
@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.