Modeling your App's User Session(github.com)
github.com
Modeling your App's User Session
https://github.com/blog/1661-modeling-your-app-s-user-session
4 comments
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.
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.
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.
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.
Add a hash of the userAgent in the session. How about adding some shared secret in the browser's localStorage?
I really like this. The session holds a lot of information about how your users are using your app. You can get the same information with analytics etc. but having it available in the DOM is really nice.
Is this supposed to be a novel idea? I don't understand why Github is showing how to do such basic stuff, or why it is being upvoted.
I've been developing web applications for 15 years and I've lost count of how many times I've built some form of sessions. I learnt some neat tricks from this article (mixing signed cookie sessions for logged out users with database backed sessions for signed in, having a revoked_at field) that I hadn't used before. Definitely worth an up vote.
What the crap?
Care to elaborate?
It was purely an accident. Haven't even read the article.
I am worth to be punished.
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.