gpt4 book ai didi

java - 缓解 Java 中针对 https 请求的 session 劫持

转载 作者:行者123 更新时间:2023-12-04 22:43:33 30 4
gpt4 key购买 nike

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

上下文.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 确认更改已生效:

enter image description here :

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

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

最佳答案

The attacker can then provide a legitimate web application session ID and try to make the victim's browser use it



以上称为 session fixation .

为了减轻成功登录后的 session 固定,暂时存储用户信息,使当前 session 无效,创建新 session ,将用户信息复制到新 session 。

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

关于java - 缓解 Java 中针对 https 请求的 session 劫持,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/61167139/

30 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com