无法理解重新生成会话id

Question

我刚从这个atricle学到了会话固定攻击。

http://shiflett.org/articles/session-fixation

但是为了防御这次攻击，我不明白session_regenerate_id()的用法是什么？

当攻击者在url中包含会话id并对服务器说我希望使用此会话时，所以与此会话相关的所有会话变量都是他的，那么为什么重新生成id是有用的呢？

谢谢

Answer 1

在网站的整个生命周期中，将会有许多“会议”。每个会话都由一个ID标识，网站如何知道谁是谁，并能够在不同请求之间保持状态。

会话固定攻击是真正有可能的，只有当你能够获得会话id。有些站点允许会话在不同的实际浏览会话(又名“记住我”功能)之间持久化，如果使用相同的会话id，则更容易受到这种攻击。

如果我获得了您的会话id，那么我只能在会话id有效的情况下才能模拟您。使用session_regenerate_id，旧的ID就失效了，对任何可能截获它的人来说都是无用的。如果用户成功身份验证后生成新ID，则捕捉会话标识符的任何尝试都将不再为经过身份验证的用户生成有效标识符(只有用户身份验证之前的“匿名”会话)，这意味着攻击者只能“模拟”匿名用户。

一些更有安全意识的框架实际上在浏览会话(使用2-3分钟的超时时间)内重新生成会话id，而不是仅仅在用户登录时帮助防止人们通过网络上的数据包嗅探获取会话id。只能响应请求重新生成会话ID。

Answer 2

要记住的关键一点是，为了维护会话状态，客户端在每次请求时都向服务器报告其当前会话id。报告机制本身(例如通过cookie或URL参数)在这里并不重要。

从服务器的角度来看，并排除了采取的高级预防措施，客户端报告的会话id是权威的:对于任何特定客户端，服务器没有“正确”或“真实”会话id的概念。客户就是他们所说的那种人。

当然，这就引出了一个问题:那么是什么阻止我声明我是一个拥有在您的应用程序上做任何事情的权限的站点管理员呢？只知道我不知道真正管理员的会话id (假设真正的管理员确实有会话)。如果我这样做了，我可以冒充管理员，做他们能做的一切。

因此，现在从攻击者的角度来看:我如何才能了解管理员的会话id？欺骗管理员向服务器报告一个我自己选择的特定会话id将有效！这就是会话固定攻击的本质。

有几种方法可以防止或减轻这种攻击的影响，其中之一是让服务器告诉客户端“我更改了您的会话id；从现在起，使用此方法”。当然，客户端不会被迫遵守，但是友好的客户端当然会这样做(即使客户是敌对的，服务器也可以拒绝识别客户端)。因此，即使攻击者设法欺骗管理人员使用攻击者已知的特定会话id，只要服务器不指示客户端切换到不同的会话id，攻击也会工作。

这正是session_regenerate_id所做的。

1高级预防措施:例如，服务器可能跟踪客户端为每个会话id使用的最后一个IP地址。如果服务器看到来自不同IP地址的给定会话id的请求，则可以认为这是可疑的。当然，这个简单的例子不能解释现代互联网基础设施的复杂程度，但这个想法是明确的。高度安全的服务(如Gmail)使用相同类型的复杂技术来检测和防止可疑活动。

Answer 3

会话ID在URL中，攻击者以某种方式让另一个用户访问这个URL，攻击者将知道会话ID。

例如，假设攻击者将此代码片段放置在自己的网站"evil.com“上(为简洁起见，对会话ID进行了修剪)

<a href="https://www.example.com/login.php?PHPSESSID=a123">Login to site to continue</a>

然后诱使受害者访问他们的网站(例如，给他们发一封包含“evil.com”链接的电子邮件)。如果用户访问攻击者网站，然后跟踪到"example.com“的链接，然后登录，攻击者可能会遵循相同的链接，劫持现在登录的会话(因为ID将匹配)。例如，这个链接可以指向Facebook上的一个有趣的视频，但是会在URL中包含会话ID，而不仅仅是一个直接的登录页面。

但是，如果session_regenerate_id()作为登录过程的一部分被调用(在确认用户名和密码之后)，会话ID将是新的，攻击者将无法使用此方法劫持会话。

这不是仅限于URL中的会话is的漏洞。假设网站的其余部分是HTTP，登录后会话被移动到HTTPS，那么重新生成会话ID也是明智的，因为当流量在HTTP上时，可能已经截获了现有的会话ID。