仅在第一次请求时拥有 Jsessionid 的漏洞是什么
最近，我们从 URL 中删除了 jsessionid，进行了基于 cookie 的会话管理，以防止“会话劫持攻击”，
但我们发现，当启用 cookie 时，第一个请求 URL 始终具有 jsessionid，而后续请求 URL 则没有 jsessionid。
使用第一个网址中的 jsessionid 我们可以直接访问工作流程中的其他页面
问题：是否存在仅在第一个请求时暴露 jsessionid 的安全漏洞？
有一个解决方案可以从第一个请求中删除 jsessionid ，但想要检查一下，是否真的很容易强制进行更改，
谢谢 J
编辑：我的疑问得到了澄清。感谢您的回复。
Recently we removed jsessionid from URL did cookies based session management to prevent "session hijacking attack"
But we found that first request URL always has jsessionid when cookies are enabled and subsequent request URL has NO jsessionid.
using the jsessionid from first url we could directly hit other pages in the workflow
Question : is there any security vulnerability exposing jsessionid only on first request?
There is a solution to remove jsessionid from first request , but wanted to check , if its really vulnerable to mandate the changes
thanks
J
EDIT : I got my doubt clarified. Thanks for replies.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您在此处所做的操作可以在一定程度上提高解决方案的整体安全性，但不一定能防止会话劫持。
将会话 ID 放在 URL 中的安全问题是 URL 会暴露在各个位置（例如，复制和粘贴 URL 可能会暴露实时会话，URL 可能存储在代理服务器日志、Web 服务器日志和浏览器历史记录中），这可能允许攻击者获取有效的会话 ID 并访问您的用户数据。
理想情况下，您应该从 URL 中的所有位置删除 JSESSIONID，并且仅使用 cookie 存储。
此外，如果您想减轻会话劫持，还需要考虑许多其他方面。
您需要在传递会话 ID 的所有页面上使用 SSL（这是为了降低会话 ID 在传输过程中被截获的风险（例如 Firesheep 攻击）。
如果在对用户进行身份验证之前设置了会话 ID，则您可以应确保在用户登录时发出新的会话 ID。
应该使用 httpOnly 和 secure 标志，以减少它们通过明文通道泄露的风险。
此外，如果可能的话，会话 cookie OWASP 站点
顺便说一句，如果您对安全方面有更多疑问，这里有一个专门用于解决问题的堆栈交换站点位于 Security.stackexchange.com
What you've done here could improve the overall security of the solution somewhat, but won't necessarily prevent session hijacking.
the security issue with placing the session ID in the URL is that URLs are exposed in various places (eg, copy and pasted URLs could expose a live session, URLs can be stored in proxy server logs, web server logs and browser history), which could allow an attacker to grab a valid session ID and get access to your users data.
Ideally you should remove the JSESSIONID from the URL in all places, and only use cookie storage.
Additionally if you want to mitiate Session hijacking there's a number of other areas to consider.
You need to use SSL on all pages where the session ID is passed (this is to mitigate the risk of the session ID being intercepted in transit (eg, the Firesheep attack).
If the session ID is set before you authenticate the user, you should ensure that a new session ID is issued when the user logs in.
Also if possible the session cookies should be use of the httpOnly and secure flags, to reduce the risk of them being leaked over cleartext channels.
There's some good additional information on the OWASP Site
BTW if you've got more question on the security side of things, there's a stack exchange site specifically for that at Security.stackexchange.com
什么阻止cookie被劫持？
会话管理是服务器端的事情 - 您需要服务器来检查（基于 cookie）用户是否已登录。
说实话，我认为您根本没有提高这里的安全性，请看一下这篇优秀文章了解原因。
Whats stopping the cookie being hijacked?
Session managment is a server side thing - You need to server to check (based on the cookie) that the user is meant to be logged in.
I don't think you've improved security here at all to be honest, take a look at this excellent article to see why.
如果有人掌握了会话 ID，那么他们几乎劫持了整个会话，请参阅 可预测的会话 ID 漏洞。
If someone gets hold of the session id then they pretty much hijack the whole session, see Predictable Session IDs vulnerability.