仅在第一次请求时使用 Jsessionid 的漏洞是什么 [英] what is the vulnerability of having Jsessionid on first request only

查看:120
本文介绍了仅在第一次请求时使用 Jsessionid 的漏洞是什么的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

最近我们从 URL 中删除了 jsessionid 做了基于 cookie 的会话管理以防止会话劫持攻击"

Recently we removed jsessionid from URL did cookies based session management to prevent "session hijacking attack"

但是我们发现在启用cookies时第一个请求URL总是有jsessionid,而后续请求URL没有jsessionid.

But we found that first request URL always has jsessionid when cookies are enabled and subsequent request URL has NO jsessionid.

使用第一个 url 中的 jsessionid 我们可以直接访问工作流中的其他页面

using the jsessionid from first url we could directly hit other pages in the workflow

问题:是否存在仅在第一次请求时暴露 jsessionid 的安全漏洞?

有一个解决方案可以从第一个请求中删除 jsessionid,但想检查一下,如果它真的容易受到强制更改的影响

There is a solution to remove jsessionid from first request , but wanted to check , if its really vulnerable to mandate the changes

谢谢

我的疑问得到了澄清.感谢回复.

EDIT : I got my doubt clarified. Thanks for replies.

推荐答案

您在这里所做的可以在一定程度上提高解决方案的整体安全性,但不一定能防止会话劫持.

What you've done here could improve the overall security of the solution somewhat, but won't necessarily prevent session hijacking.

在 URL 中放置会话 ID 的安全问题是 URL 会暴露在不同的地方(例如,复制和粘贴的 URL 可能会暴露实时会话,URL 可以存储在代理服务器日志、Web 服务器日志和浏览器历史记录中)),这可能允许攻击者获取有效的会话 ID 并访问您的用户数据.

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.

理想情况下,您应该从所有位置的 URL 中删除 JSESSIONID,并且仅使用 cookie 存储.

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.

您需要在传递会话 ID 的所有页面上使用 SSL(这是为了降低会话 ID 在传输过程中被拦截的风险(例如 Firesheep 攻击).

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).

如果在对用户进行身份验证之前设置了会话 ID,则应确保在用户登录时发出新的会话 ID.

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.

此外,如果可能,会话 cookie 应使用 httpOnly 和安全标志,以降低它们通过明文渠道泄露的风险.

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.

OWASP 站点

顺便说一句,如果您对事物的安全性有更多疑问,Security.stackexchange.com 上有一个专门针对此问题的堆栈交换站点一个>

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

这篇关于仅在第一次请求时使用 Jsessionid 的漏洞是什么的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆