[samarudge]

Would adding a HMAC string to the cookie value not get around this issue? For example, Tornado has the set_secure_cookie method (http://www.tornadoweb.org/en/stable/web.html#tornado.web.Req...), would this not prevent this sort of attack? Even if a script modified the cookies, they would never (well, hopefully never) be able to generate the correct HMAC token so the server could just discard the cookies. You'd still be able to sign a user out but there wouldn't be a security issue (I think). Anyone smart able to verify/refute?

[jcampbell1]

> Would adding a HMAC string to the cookie value not get around this issue?

That would do absolutely nothing. Here are the attacks:

1) log a person out by replacing the session cookie

2) make github slower by making all requests have to send a large amount of cookie data.

3) Log someone in to one of the attackers accounts. For instance I can create an account like `jResîg`, and log people into that account.

Adding an HMAC prevents 0 of 3. Moving github pages to a different domain solves all three problems.

[X-Istence]

You as the attacker can visit the page and get yourself a session cookie that is valid and set that on the victim's computer...

[samarudge]

Would it increase security to include the user-agent, or part of the user-agent, in the HMAC secret? So the secret was "abc123Mozilla[etc]", that would then presumably require identical browsers to work, at the expense of logging everyone out every time their browser updates. Or include all, or part of the IP address to restrict the network.

[duskwuff]

No, that's not useful. Cookie tossing attacks need not generate their own cookies -- it's just as effective, if not more so, to toss cookies for a session that was generated for another user.