传递会话ID作为url参数的危害 [英] Harm of passing session id as url parameter

查看:209
本文介绍了传递会话ID作为url参数的危害的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所以我只是注意到,其中一个互联网银行网站正在传递会话ID作为url参数。 (见下图)

So I just noticed that one of the internet banks websites is passing session id as url parameter. ( See image below )

我以前在网址中没有看到;,在这种情况下,它是在'private;'之后。

I didn't previously see anywhere that ';' in url, in this case it is after 'private;'.

1)这个';'的用途是什么?

1) What is the use of this ';'?

需要在安全的地方在互联网是传递会话ID作为url参数?

2) And why internet bank, which needs to be securest place in the internet is passing session id as url parameter?

一开始,我认为他们是这样做的,因为一些用户不允许使用cookie,但是如果他们允许使用cookie,则再次使用cookie,如果没有 - url ,但我确实允许使用cookie,所以显然不是这样。

At first, I thought they are doing it because some of the users disallow use of cookies, but then again, if they allow it, use cookies, if not - url, but I do allow use of cookies, so obviously thats not the case.

3)我猜他们应该有其他安全措施吗?他们可以是什么?

3) I guess then they should have some other security measures? What they could be?

4)如果他知道其他有效的会话ID,可以做什么?
我知道,如果你知道id,你可以很容易地登录其他人的会话,因为它不难编辑cookie,它更容易通过会话id作为url参数,特别是如果你有类似:

4) And what one can possibly do if he knows others valid session id? As I know, you can quite easily log into others peoples session if you know that id, because its not hard to edit cookies and its much easier to pass that session id as url parameter, especially if you have something like:

session_id($ _ GET [sessionid]);

谢谢!

推荐答案

1)你应该问问谁设计的应用程序, URL可以是任何你想要的; key = value& key2 = value2 的约定就是一个约定。在这种情况下,它是Java,它通常使用; jsessionid = .... 作为其SID。

1) You should ask whoever designed the application your red box is covering. URL can be anything you want; the convention of key=value&key2=value2 is just that - a convention. In this case, it's Java, and it commonly uses the convention of ;jsessionid=.... for its SID.

2)这不是那么大的交易。正常用户不能复制粘贴cookie,因为他们可以复制粘贴GET参数,但高级用户可以做任何他们想要的(使用Mechanize, wget curl 和其他非浏览器手段,甚至浏览器扩展)。如果你允许某些用户允许,不允许某些用户使用,这不是一个安全预防措施,是吗?基本上,cookie SID会使攻击更难一点,但它就像把你的前门钥匙放在垫子 - 绝对不能保持你的门安全。此外,标签之间共享Cookie:如果网站要求您同时使用两个帐户登录,则无法使用Cookie。

2) It's not that big of a deal. Normal users can't copy-paste cookies like they can copy-paste a GET parameter, but power users can do whatever they want (using Mechanize, wget, curl and other non-browser means, or even browser extensions). And if you allow it for some users and disallow for some, it's not really much of a security precaution, is it? Basically, cookie SID will make the attack a bit harder, but it's like putting your front door key under the mat - definitely doesn't keep your door secure. Additionally, cookies are shared between tabs: if a site wants you to be logged in with two accounts at once, you can't do it with cookies.

3)Serverside安全,是的。一个有效的对策是一次性SID(每次访问页面时,服务器从当前SID读取会话,然后使用新的SID为下一个请求启动新会话)。一个不太有效但仍然好的方法是验证其他信息的一致性(例如 - 仍然相同的IP?仍然同一个浏览器?)

3) Serverside security, yes. One effective countermeasure is one-time SIDs (each time you visit a page, the server reads the session from the current SID, then starts a new session with a new SID for the next request). A less effective but still good method is to validate other information for consistency (e.g. - still same IP? Still same browser?)

4)是的,如果你知道某人的有效SID,并且服务器没有充分保护会话固定,您可以成为该人。例如,这可能使攻击者能够用你的钱支付账单。

4) Yes, if you know someone's valid SID, and the server does not adequately protect against session fixation, you can "become" that person. This might enable the attacker to, say, pay his bills with your money, for instance.

这篇关于传递会话ID作为url参数的危害的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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