浏览器关闭后保持会话
如何安全地实现维护会话。假设只有登录页面使用 SSL。因此，用户输入他的用户名密码，http 服务器会验证它是否在数据库中，然后怎么办？
它设置了一些cookie吗？如果是这样，那么应该将 cookie 设置为什么以维护安全性（加密，哪种加密）？寻找低级详细答案。我听说存在各种 cookie 劫持问题。如果我只使用 SSL 进行登录，但此后不使用 SSL，cookie 是否会容易受到攻击？
那么当浏览器关闭、用户回来后，cookie是如何识别用户名的呢？如何安全地完成此操作而不导致 cookie 被盗？
How does one implement maintaining sessions securely. Suppose just the login page uses SSL. So the user enters his usernamepassword and the http server verifies it is in the database and now what?
Does it set some cookie? If so then what should the cookie be set to so that security is maintained (encrypted, what kind of encryption)? Looking for a low level detailed answer. I hear there are various cookie hijacking concerns. If I only use SSL for the login but thereafter don't use SSL will the cookie be vulnerable?
Then after the browser is closed and the user comes back how does the cookie identify the username. How is this done securely without the cookie being stolen?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您的连接没有始终加密，您肯定就会使您的客户端面临会话被盗的风险。
HTTP 是无状态协议，因此伪造有状态交互的唯一方法是客户端和服务器在每次事务中发送会话标识符。如果不加以保护，它很可能会被盗。由于会话标识符是开放会话期间唯一的身份验证令牌，因此这是灾难性的。
实现“记住我”功能的通常方法是设置一个 cookie，其生命周期不限于浏览器的程序生命周期（即通过设置明确的到期日期），并在 cookie 中存储一些唯一的数据，您可以将这些数据与某些数据相匹配。记住数据库中的数据（可能包括 IP）。但这并不能免除您对所有通信进行加密的需要！
You definitely expose your clients to session theft if your connection is not encrypted at all times.
HTTP is a stateless protocol, so the only way to fake a stateful interaction is for client and server to send a session identifier with every transaction. If this isn't protected, it can trivially be stolen. Since the session identifier is the only authentication token during the open session, this is catastrophic.
The usual way to make a "remember me" feature would be to set a cookie whose lifetime is not limited to the browser's program lifetime (i.e. by setting an explicit expiration date), and storing some unique data in the cookie which you match against some remembering data (including the IP perhaps) in your database. But that does not absolve you from the need to encrypt all communication!