我刚从这个心房学习会话固定攻击
http://shiflett.org/articles/session-fixation
但为了防御这次攻击，我不明白session_regenerate_id（）的用法是什么？
当攻击者在url中包含会话ID并对服务器说我想要使用此会话时，所有与此会话相关的会话变量都适合他，那么为什么重新生成id很有用呢？
感谢
答案 0 :(得分：2)
在网站的整个生命周期中，会有很多“会话”。每个会话都由一个ID标识，并且是网站如何知道谁是谁以及能够在不同请求之间保持状态。
如果你能得到会话ID ，会话固定攻击真的只有。某些站点允许会话在不同的实际浏览会话（即“记住我”功能）之间保持不变，并且如果使用相同的会话ID，则更容易受到此攻击。
如果我得到你的会话ID，那么只要会话ID有效，我就可以冒充你。使用session_regenerate_id，旧ID无效，对任何可能截获它的人都没用。如果您在用户成功验证自己后生成新ID，则捕获会话标识符的任何尝试都将不再为经过身份验证的用户生成有效标识符（仅限用户在验证自身之前拥有的“匿名”会话） ，意味着攻击者只能“冒充”匿名用户。
更多安全意识的框架实际上会在浏览会话中重新生成会话ID（使用超时低至2-3分钟），而不是仅仅在用户登录时帮助防止人们通过数据包嗅探来抓取会话ID网络。只能重新生成会话ID以响应请求。
答案 1 :(得分：2)
要记住的关键点是，为了维护会话状态，在每个请求上，客户端将其当前会话ID报告给服务器。报告机制本身（例如通过cookie或URL参数）在这里并不重要。
从服务器的角度来看，并且不包括采取的高级预防措施¹，客户端报告的会话ID是权威的：服务器没有任何特定客户端的“正确”或“真实”会话ID的概念。客户就是他们所说的人。
当然，这提出了一个问题：那么是什么阻止我声明我是一个有权在您的应用程序上执行任何操作的站点管理员？只有我不知道真实管理员的会话ID的事实（假设真正的管理员确实有会话）。如果我这样做，我可以冒充管理员并尽其所能。
现在从攻击者的角度来看：我怎样才能学习管理员的会话ID？欺骗管理员向服务器报告我自己选择的特定会话ID将起作用！这是会话固定攻击的本质。
有几种方法可以防止或减轻这种攻击的影响，其中一种方法是让服务器告诉客户端“我改变了你的会话ID;从现在开始，使用这个”。当然，客户不是强制遵守，但友好的客户当然会这样做（并且服务器即使他们是敌对的，也可以拒绝识别客户）。因此，即使攻击者设法欺骗管理员使用攻击者已知的特定会话ID，只要服务器不指示客户端切换到不同的会话ID，攻击就会起作用。
这正是session_regenerate_id所做的。
¹高级预防措施：例如，服务器可能会跟踪客户端为每个会话ID使用的最后一个IP地址。如果服务器看到具有来自不同IP地址的给定会话ID的请求，那么这可能被认为是可疑的。当然，这个简单的例子无法解释现代互联网基础设施的复杂性，但这个想法很清楚。高安全性服务（例如Gmail）使用相同类型的复杂技术来检测和防止可疑活动。
答案 2 :(得分：1)
会话ID在URL中，并且攻击者以某种方式让另一个用户访问此URL，攻击者将知道会话ID。
e.g。假设攻击者将此代码段放在他们自己的网站“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中的会话ID的漏洞。假设网站的其余部分是HTTP，并且在登录后会话被移动到HTTPS，那么重新生成会话ID也是明智的，因为当流量在HTTP上时，现有的会话ID可能已被截获。