最近我们从 URL 中删除了 jsessionid，做了基于 cookie 的会话管理，以防止“会话劫持攻击”
但是我们发现，当启用 cookie 时，第一个请求 URL 总是有 jsessionid，而后续请求 URL 没有 jsessionid。
使用第一个 url 中的 jsessionid 我们可以直接点击工作流中的其他页面
问题：是否有任何安全漏洞仅在第一次请求时暴露 jsessionid？
有一个从第一个请求中删除 jsessionid 的解决方案，但想检查它是否真的容易受到强制更改的影响
谢谢J
编辑：我的疑问得到了澄清。感谢您的回复。
您在这里所做的可以在一定程度上提高解决方案的整体安全性，但不一定能防止会话劫持。
将会话 ID 放在 URL 中的安全问题是 URL 会暴露在不同的地方（例如，复制和粘贴的 URL 可能会暴露实时会话，URL 可以存储在代理服务器日志、Web 服务器日志和浏览器历史记录中），这可能允许攻击者获取有效的会话 ID 并访问您的用户数据。
理想情况下，您应该从所有位置的 URL 中删除 JSESSIONID，并且只使用 cookie 存储。
此外，如果您想减轻会话劫持，还有许多其他方面需要考虑。
您需要在传递会话 ID 的所有页面上使用 SSL（这是为了降低会话 ID 在传输过程中被拦截的风险（例如 Firesheep 攻击）。
如果在对用户进行身份验证之前设置了会话 ID，则应确保在用户登录时发布新的会话 ID。
此外，如果可能，会话 cookie 应使用 httpOnly 和安全标志，以降低它们通过明文通道泄露的风险。
OWASP 网站上有一些很好的附加信息
顺便说一句，如果您对事物的安全性有更多疑问，Security.stackexchange.com 上有一个专门针对此问题的堆栈交换站点
做了基于cookies的会话管理来防止“会话劫持攻击”
是什么阻止了 cookie 被劫持？
会话管理是服务器端的事情 - 您需要服务器检查（基于 cookie）用户是否要登录。
老实说，我认为您根本没有提高这里的安全性，请查看这篇出色的文章以了解原因。
如果有人掌握了会话 ID，那么他们几乎劫持了整个会话，请参阅可预测的会话 ID漏洞。