是什么阻止了HttpSession的id被盗?

Bri*_*asa 6 java security servlets java-ee httpsession

在Java Servlet API中,如何确保某人的会话ID不被盗?

例如,如果我有一个活跃的会话,而某人以某种方式获得我的会话ID,他们可以使用它吗?

bob*_*nce 12

什么都没有阻止它.您获得会话ID,您可以参加会话.

在通常的cookie情况下,这本身并不存在风险.攻击者不应该能够读取用户的会话cookie,除非:

  1. 他们有中间人的能力,在这种情况下,你遇到的问题比会话ID要严重得多;

  2. 你已经离开了一个跨站点脚本漏洞,在这种情况下,你遇到的问题比会话ID要严重得多;

  3. 您很容易受到DNS重新绑定/跨域烹饪攻击,在这种情况下,您应该通过仅允许已知好的Host:请求来修复它.

(虽然您可以尝试将会话绑定到IP地址,但由于例如循环代理,这可能会破坏有效会话.IP可以用作检测可疑活动的更广泛策略的一部分,但在公共互联网上,它始终不是一个好主意要求会话中的每个请求来自相同的IP.)

不幸的是,在Servlet中还有另一种情况,除了cookies:jsessionid=参数.由于它们出现在URL本身,这使得他们更能泄漏(例如,通过引荐并粘贴链接).这与参数会话ID的唯一实际问题相去甚远.他们搞乱了导航和破坏搜索引擎优化.

在我看来 jsessionid= URL是Servlet最糟糕的早期错误之一,是昔日的一种不可信任的cookie后备策略,不应该用于任何事情.但当然不应允许他们授予对任何特权数据的访问权限; 如果您需要针对不支持cookie的浏览器的回退机制,请考虑使用HTTP基本身份验证.

在Servlet的3.0,您可以禁用jsessionid=使用易于网址<session-config>web.xml; 不幸的是,在以前的版本中,如果要正确禁用该功能,则会使用过滤器.


Ala*_*nse 8

是的,他们可以使用它.除非您将所有流量都通过SSL,否则无法保护它.

这就是Firesheep的工作方式,最近因为简化会话窃取而引起了很多关注.

  • 是的,您发送给用户的任何信息都可以被截获,因此加密确实是阻止它的唯一方法.至于猜测,通常会话ID设计得足够难以猜测这是不切实际的. (3认同)