缓解 Java 中针对 https 请求的会话劫持

Posted 2023-03-08

【中文标题】缓解 Java 中针对 https 请求的会话劫持

【英文标题】：Mitigating session hijacking in java for an https request

【发布时间】：2020-07-24 18:53:37

【问题描述】：

我已经在 tomcat context.xml 中设置了useHttpOnly=true，并且正在使用在 server.xml 连接器元素支持中使用 java keytool 生成的自签名证书来支持 SSL，如下所示：

context.xml

<Context useHttpOnly="true">
<!-- other code -->
</Context>

服务器.xml

<Connector port="80" protocol="HTTP/1.1" 
               connectionTimeout="20000" 
               redirectPort="8443" />

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
            maxThreads="150" scheme="https" secure="true"
            clientAuth="false" sslProtocol="TLS" 
            keystoreFile="my key file location"
            keystorePass="keystore password" />

重启服务器后，我已经使用chrome dev tools确认更改已经生效：

:

我猜这实际上并不能使站点免受会话劫持，因为如果攻击者能够通过嗅探获得有效的会话 ID。如果让用户使用已知的会话 ID 对自己进行身份验证，然后通过知道所使用的会话 ID 来劫持用户验证的会话。然后，攻击者可以提供一个合法的 Web 应用程序会话 ID，并尝试让受害者的浏览器使用它。

我已经使用 burp 套件进行了测试，方法是嗅探用户（具有管理员角色）的会话 ID，并将其用作具有另一个角色的用户的会话 ID。服务器无法识别活动会话请求是来自原始设备还是来自非法使用会话的攻击者。我想这就是 SSL 的用武之地！浏览器不信任我的自签名证书，这让我想知道如果我使用其他 SSL 会有多么不同。它真的让我的网站比自签名证书更安全吗？或者如果从浏览器的角度来看，它只是证书的可信度？服务器有什么方法可以检查请求是否来自经过身份验证的用户而不是劫持会话的攻击者？

【问题讨论】：

如果攻击者能够通过嗅探获得有效会话 ID 攻击者如何从加密流量中“嗅探”有效会话 ID？至于不信任您的自签名证书，问题在于用户是否会信任您的网站；它为嗅探攻击添加了 zero 额外保护。顺便说一句，SSL 更恰当地称为传输层安全性 (TLS) - 它可用于向任何 TCP 协议（​​不仅仅是 HTTP）添加加密。你可以使用 TLS 做一些interesting 的事情。

“问题在于用户是否会信任您的网站；它对嗅探攻击添加了零额外保护”——是的，但除此之外，就证书而言，有什么不同吗？ “如果攻击者能够通过嗅探获得有效会话 ID 攻击者如何从加密流量中“嗅探”有效会话 ID” - 我使用 burp 套件拦截流量并能够获取所有数据已在请求中转移。

就证书而言有什么不同吗？ 没有。只有当最终用户无法验证您的证书时，中间人攻击才有可能。通常的方法是使用签名证书。但是如果攻击者也可以生成有效的签名证书，那么可以；你仍然容易受到中间人攻击。这不是新的。

我想我已经理解了对有效证书的需求，而且似乎有效证书并不一定意味着攻击者不能破坏用户会话。有没有办法在服务器端检查请求是否被泄露？

当然。客户端上的有效证书，服务器上的有效证书，执行双向验证。现在每个客户都必须经过验证。密码学文献非常好，或者你可以继续在互联网上询问陌生人向你解释数学。

【参考方案1】：

然后，攻击者可以提供一个合法的 Web 应用程序会话 ID 并尝试让受害者的浏览器使用它

上面叫session fixation。

为了在成功登录后缓解会话固定，暂时存储用户信息，使当前会话无效，创建新会话，将用户信息复制到新会话。

这样，如果攻击者使用他生成的会话 ID，该会话将不会是受害者的会话。

【讨论】：

这已经使用 spring 自己的会话管理配置完成了。登录后会话 ID 发生变化。我的问题是攻击者已经与他有一个有效的会话 ID，并让另一个登录的受害者使用它。