什么可以防止 HttpSession 的 id 被盗？
在Java Servlet API中，如何确保某人的会话ID不被窃取？
例如，如果我有一个活动会话，并且有人以某种方式获取了我的会话 ID，他们可以使用它吗？
In the Java Servlet API, what is done to ensure that someone's session id is not stolen?
For example, if I had an active session and someone somehow get a hold of my session id, could they use it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
没有什么可以阻止它。您获得会话ID，即可参加会话。
在通常的 cookie 情况下，这本身并不是一个风险。攻击者不应该能够读取用户的会话 cookie，除非：
他们具有中间人能力，在这种情况下，你会遇到比会话 ID 更糟糕的问题；
你留下了一个跨站点脚本漏洞，在这种情况下，你会遇到比会话 ID 更糟糕的问题；
您很容易受到 DNS 重新绑定/跨域烹饪攻击，在这种情况下，您应该通过仅允许已知良好的
Host:请求来修复它。（虽然您可以尝试将会话绑定到 IP 地址，但这可能会由于循环代理等原因而破坏有效会话。IP 可以用作检测可疑活动的更广泛策略的一部分，但在公共互联网上，这始终不是一个好主意要求会话中的每个请求都来自同一个 IP。）
不幸的是，在 Servlet 中，除了 cookie 之外，还有另一种情况：
jsessionid=参数。由于它们出现在 URL 本身中，这使得它们更加容易泄漏（例如，通过引荐来源网址和粘贴的链接）。这远非参数会话 ID 的唯一实际问题。他们搞乱了导航并破坏了搜索引擎优化。在我看来，
jsessionid=URL 是 Servlet 早期最严重的错误之一，是一种不值得信赖的 cookie 回退策略，不应该用于任何用途。但当然不应该允许他们授予对任何特权数据的访问权限；如果您需要为不支持 cookie 的浏览器提供回退机制，请考虑使用 HTTP 基本身份验证。在 Servlet 3.0 中，您可以使用
web.xml中的jsessionid=URL；不幸的是，在以前的版本中，如果您想正确禁用该功能，您只能使用过滤器。Nothing prevents it. You get the session ID, you can take part in the session.
In the usual case of cookies this is not a risk in itself. The attacker should not be able to read a user's session cookie unless:
they've got man-in-the-middle capability, in which case you've got much worse problems than just session IDs;
you've left a cross-site-scripting hole, in which case you've got much worse problems than just session IDs;
you're vulnerable to DNS-rebinding/cross-domain-cooking attacks, in which case you should fix it by only allowing known-good
Host:requests.(Whilst you can try tying sessions to IP addresses, this risks breaking valid sessions due to eg round-robin proxies. IPs can be used as part of a wider strategy for detecting suspicious activity, but on the public internet it's not a good idea always to require each request in a session to come from the same IP.)
Unfortunately in Servlet there is another case, apart from cookies:
jsessionid=parameters. Since they appear in the URL itself, that makes them much more leaky (eg via referrers and pasted links). And that's far from the only practical problem with parameter session IDs. They mess up navigation and wreck SEO.In my opinion
jsessionid=URLs are one of Servlet's worst early mistakes, a discredited cookie fallback strategy from yesteryear that shouldn't be used for anything. But certainly they shouldn't be allowed to grant access to any privileged data; consider using HTTP Basic Authentication instead if you need a fallback mechanism for browsers that don't support cookies.In Servlet 3.0 you can disable
jsessionid=URLs easily using<session-config>in theweb.xml; unfortunately in previous versions you are left mucking around with filters if you want to properly disable the feature.是的，他们可以使用它。除非您将所有流量都通过 SSL 传输，否则不会采取任何措施来保护它。
这就是 Firesheep 的工作原理，它最近因轻松窃取会话而受到广泛关注。
Yes, they could use it. Nothing is done to protect it unless you put all your traffic over SSL.
This is how Firesheep works, which recently got a lot of attention for making session stealing easy.
是的，会话 ID 允许某人访问相应的会话。
您可以将登录期间使用的 IP 存储在会话中，并且当 IP 更改时需要用户再次登录。
另外（虽然不确定这是否是自动完成的）你可以对用户代理做同样的事情 - 但并没有真正提高针对恶意攻击的安全性，只是防止愚蠢的用户意外地泄露他们的 sessionid（如果它是通过 GET 而不是 cookie 传递的）。
Yes, the Session ID gives someone access to the corresponding session.
You could store the IP used during login in the session and when the IP changes require the user to login again.
Additionally (not sure if that's done automatically though) you could do the same for the User Agent - not really increasing safety against malicious attacks though, just against dumb users giving away their sessionid accidentally if it's passed via GET and not a cookie.