将会话ID作为url参数传递的危害
use*_*573 3 security cookies session sessionid web
所以我只注意到其中一个互联网银行网站将会话ID作为url参数传递.(见下图)
我之前没有看到过';' 在url中,在这种情况下它位于'private;'之后.
1)这个';'有什么用？
2)为什么需要在互联网上最安全的互联网银行将会话ID作为url参数传递？
起初,我认为他们这样做是因为有些用户不允许使用cookie,但是如果他们允许的话,再次使用cookie,如果不是 - url,但我允许使用cookie,所以很明显不是这样的.
3)我猜他们应该有其他一些安全措施吗？他们可能是什么？
4)如果他知道其他有效的会话ID,他可以做什么？据我所知,如果你知道id,你可以很容易地登录其他人会话,因为它不难编辑cookie,并且更容易将该会话id作为url参数传递,特别是如果你有类似的东西:
session_id($_GET[sessionid]);
谢谢!
1)您应该询问红盒子所覆盖的应用程序的设计者.URL可以是您想要的任何内容; 惯例key=value&key2=value2只是 - 一个惯例.在这种情况下,它是Java,它通常使用;jsessionid=....其SID 的约定.
2)这不是什么大不了的事.普通用户不能复制粘贴cookie,就像他们可以复制粘贴GET参数一样,但高级用户可以做任何他们想做的事情(使用Mechanize wget,curl和其他非浏览器方式,甚至是浏览器扩展).如果你允许某些用户使用它而不允许某些用户,那么这不是一个安全预防措施,是吗？基本上,cookie SID会使攻击更加困难,但这就像把你的前门钥匙放在垫子下面 - 绝对不会保证你的门安全.此外,Cookie在标签之间共享:如果网站希望您同时使用两个帐户登录,则无法使用Cookie.
3)服务器安全性,是的.一个有效的对策是一次性SID(每次访问页面时,服务器从当前SID读取会话,然后为下一个请求启动具有新SID的新会话).一种不太有效但仍然很好的方法是验证其他信息的一致性(例如 - 仍然是相同的IP？仍然是相同的浏览器？)
4)是的,如果您知道某人的有效SID,并且服务器没有充分防止会话固定,您可以"成为"该人.例如,这可能使攻击者能够用你的钱支付账单.
所以,@ Amadan正确地涵盖了#1和#4.但还有一点需要扩展.
在URL中使用会话标识符可能是一个主要问题.在某些情况下,这是非常糟糕的:
会话劫持:
如果用户将URL复制粘贴到电子邮件中.
在这种情况下,攻击者可以简单地读取电子邮件,并窃取会话标识符(从而恢复会话).
您可以通过缩短会话生存期并在会话中验证IP地址或用户代理等内容来部分抵御此操作.请注意,这些都不是万无一失的,只是让它"稍微"难以攻击.
如果连接被降级为HTTP.
如果他们没有使用Http-Strict-Transport-Security(HSTS),那么攻击者可能只能成功地将会话降级为HTTP(通过MITM样式攻击).如果服务器设置不完美,则可能导致URL泄露给攻击者,从而泄露会话标识符.
会话固定攻击
攻击者可以制作会话标识符,并向用户发送具有该会话标识符的伪造链接.然后,用户登录该站点,该会话现在与其帐户绑定.
您可以通过在每次会话更改(登录,注销,权限升级或降级等)时严格轮换会话标识符来缓解此问题.但是许多服务器不这样做,因此容易受到固定式攻击.
cookie会话被认为更安全的原因并不是因为它们更难编辑.这是因为他们更能抵抗固定攻击(您无法创建URL或链接或表单或js或代表用户发送欺诈性cookie的任何内容).
为什么银行使用URL参数？我有两个猜测:
因为他们想支持那些不允许cookie的人.
这是感叹值得.
他们不知道更好.
认真.如果它不在合规性文档或NIST推荐中,那么他们可能不会这样做.地狱,已经实施了NIST的建议,这些建议被认为是不安全的,但仍然遵循,因为它是书面形式.