4 ms·
Modeling your App's User Session
- vadivlkumar 13y agoWhat the crap?
- Zikes 13y agoCare to elaborate?
- vadivlkumar 13y agoIt was purely an accident. Haven't even read the article. I am worth to be punished.
- ollysb 13y agoI 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.
- chrisrhoden 13y agoWhile it is possible to do so, the information and code provided here does absolutely nothing to prevent replay attacks. 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.
- simonw 13y agoHow would you prevent replay attacks by someone who manages to get hold of a session cookie?
- jeffasinger 13y agoOne 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.
- simonw 13y agoI use a laptop and carry it between work and home, occasionally signing in to a VPN. My IP address changes several times a day.
- woadwarrior01 13y agoAdd a hash of the userAgent in the session. How about adding some shared secret in the browser's localStorage?
- espeed 13y ago1. Embed an ephemeral encrypted token (https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Encrypted_Token_Pattern 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_requests.html 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-version-1-is-insecure.html 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-keygen-element-be-used-to-create-a-certificate-for-mutual-auth-tls-w/27967#27967 http://security.stackexchange.com/questions/27961/should-the...). 4. All of the above.
- jafaku 13y agoIs 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.
- simonw 13y agoI'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.