How would you prevent replay attacks by someone who manages to get hold of a session cookie?
1. Embed an ephemeral encrypted token (https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF...) in the HTTP response header that's signed with an HMAC-SHA-256 signature.
2. Sign sensitive requests similar to how Amazon does for AWS API requests (http://docs.aws.amazon.com/general/latest/gr/signing_aws_api...) -- just make sure your signature is secure (http://www.daemonology.net/blog/2008-12-18-AWS-signature-ver...).
3. Use client-side certificates by using the HTML5 keygen element to have the browser generate the client's public/private key pair, and then have the server sign the client's public key (http://security.stackexchange.com/questions/27961/should-the...).
4. All of the above.
Re:Modeling your App's User Session
by jeffasinger on Friday October 18, 2013 @07:05PM
(#6574543)
One technique is to hold other information along with the session cookie, such as the client IP.
This isn't perfect, because there will be false positives that log people out fairly often, but it would make session hijacking significantly harder.
I use a laptop and carry it between work and home, occasionally signing in to a VPN. My IP address changes several times a day.
Re:Modeling your App's User Session
by woadwarrior01 on Saturday October 19, 2013 @01:01AM
(#6575406)
Add a hash of the userAgent in the session. How about adding some shared secret in the browser's localStorage?
The ability to revoke sessions is nice, and somewhat related, but it's not the same as preventing replay attacks.
Aside from providing visibility into active sessions, the only other reason I can imagine this being better than signed cookies is if you didn't trust your signing algorithm and wanted to prevent someone from changing parts of your session cookie while retaining a valid signature. As far as I know, the signatures used by Rails and Django have not been called into question.