我正在尝试更深入地了解 PHP 会话固定 和劫持问题，以及如何防止这些问题。我一直在阅读 Chris Shiflett 网站上的以下两篇文章：
然而，我不确定我是否正确理解了这些内容。
为了帮助防止会话固定，仅调用 session_regenerate_id(true); 是否就足够了？我认为是这样理解的。
他还谈到使用通过 $_GET 传递的令牌来防止会话劫持。这应该怎么做？我猜测当有人成功登录时，您会生成他们的令牌并将其存储在会话变量中，然后在每个页面上，您将比较该会话变量与 $_GET 变量的值？
这个令牌是需要每个会话只更改一次还是每次页面加载都需要更改？
此外，是否有一种良好的方法可以在不必通过 URL 传递值的情况下防止劫持？这将更容易些。
http://www.example.com/index...?session_name=sessionid的URL来实现。一旦攻击者将URL提供给客户端，攻击就与会话劫持攻击相同。session.use_trans_sid = 0。这将告诉PHP不在URL中包含标识符，并且不读取URL中的标识符。session.use_only_cookies = 1。这将告诉PHP永远不要使用带有会话标识符的URL。在php.ini中使用一个强大的会话哈希标识符：session.hash_function。如果PHP版本小于5.3，则将其设置为session.hash_function = 1以使用SHA1。如果PHP版本大于等于5.3，则将其设置为session.hash_function = sha256或session.hash_function = sha512。
在php.ini中发送一个强大的哈希：session.hash_bits_per_character。将其设置为session.hash_bits_per_character = 5。虽然这并不会使破解变得更加困难，但在攻击者尝试猜测会话标识符时会有所不同。会话ID会更短，但使用更多的字符。
在php.ini文件中使用session.entropy_file和session.entropy_length设置额外的熵。将前者设置为session.entropy_file = /dev/urandom，将后者设置为从熵文件中读取的字节数，例如session.entropy_length = 256。
将会话的名称从默认的PHPSESSID更改为其他名称。在调用session_start之前，通过将自己的标识符名称作为第一个参数调用session_name()来实现。
如果你真的很偏执，你也可以定期更改会话名称，但要注意，如果你更改了会话名称（例如，如果你将其与时间相关联），所有会话将自动失效。但根据你的用例，这可能是一个选择...
经常更换会话标识符。我不会在每个请求中都这样做（除非你真的需要那种级别的安全性），而是在随机的时间间隔内更换。你希望经常更改这个，因为如果攻击者劫持了一个会话，你不希望他们能够长时间使用它。
在会话中包含来自$_SERVER['HTTP_USER_AGENT']的用户代理。基本上，当会话开始时，将其存储在类似$_SESSION['user_agent']的变量中。然后，在每个后续请求中检查它是否匹配。请注意，这可以被伪造，所以它并不是100%可靠，但比没有好。
在会话中包含来自$_SERVER['REMOTE_ADDR']的用户IP地址。基本上，当会话开始时，将其存储在类似$_SESSION['remote_ip']的变量中。这可能会对一些使用多个IP地址的ISP（例如AOL曾经使用的方式）造成问题。但如果你使用它，它将更加安全。攻击者伪造IP地址的唯一方法是在真实用户和你之间的某个网络上进行入侵。如果他们入侵了网络，他们可以做比劫持更糟糕的事情（例如中间人攻击等）。
在会话和浏览器端包含一个令牌，你可以经常递增并进行比较。基本上，对于每个请求，在服务器端执行$_SESSION['counter']++。在浏览器端使用JS执行类似的操作（使用本地存储）。然后，当你发送请求时，只需获取令牌的一个随机数，并验证服务器上的随机数是否相同。通过这样做，你应该能够检测到劫持的会话，因为攻击者将没有确切的计数器，或者如果他们确实有，你将有两个系统传输相同的计数，并且可以判断其中一个是伪造的。这种方法不适用于所有应用程序，但是是解决问题的一种方式。
会话固定和劫持的区别仅在于会话标识符的泄露方式。在固定中，攻击者事先知道标识符的值。而在劫持中，标识符要么被猜测，要么从用户那里窃取。一旦标识符被泄露，两者的影响是相同的。
每当使用session_regenerate_id重新生成会话标识符时，旧的会话应该被删除。核心会话处理程序会自动完成此操作。然而，一些使用session_set_save_handler()的自定义会话处理程序没有执行此操作，因此容易受到旧会话标识符的攻击。如果您使用自定义会话处理程序，请确保跟踪您打开的标识符，并且如果它与保存的标识符不同，您需要显式地删除（或更改）旧标识符上的标识符。
session_regenerate_id(true)即可。这将为您删除旧的会话信息。旧的ID不再有效，如果攻击者（或其他人）尝试使用它，将会创建一个新的会话。但是，对于自定义的会话处理程序要小心……session_destroy：function destroySession() {
$params = session_get_cookie_params();
setcookie(session_name(), '', time() - 42000,
$params["path"], $params["domain"],
$params["secure"], $params["httponly"]
);
session_destroy();
}
session_regenerate_id 不会使与旧 ID 关联的会话失效；只有在将 delete_old_session 参数设置为 true 时，会话才会被销毁。但如果攻击者发起了此 ID 重建，该怎么办？ - Gumbosession.entropy_file = /dev/urandom。PHP内部的熵生成被证明非常薄弱，而/dev/random或/dev/uranom提供的熵池是您在没有硬件随机数生成器的Web服务器上可以得到的最好的选择。 - rooksession.cookie_httponly 和 session.cookie_secure。第一个有助于防止 XSS 攻击（但不是完美的）。第二个是阻止 OWASP A9 攻击的最佳方法。 - rook两种会话攻击的目标相同：获取另一个用户的合法会话。但攻击向量是不同的：
在这两种攻击中，会话ID是这些攻击所关注的敏感数据。因此，对于读取访问（会话劫持）和写入访问（会话固定），需要保护会话ID。
使用HTTPS来保护敏感数据的一般规则也适用于本案例。此外，您应该执行以下操作：
为了防止会话固定攻击，请确保：
true），如果可能，请仅将其设置为 HTTPS（将 session.cookie_secure 设置为 true）；您可以使用 session_set_cookie_params 来同时完成这两个操作。为了防止会话劫持攻击，请确保：
true）为了防止两种会话攻击，请确保：
true）或权限更改后使用session_regenerate_id(true)更改会话ID并销毁旧会话。（如果您想保留与旧ID关联的会话，则请确保在重新生成ID之前使用session_write_close存储$_SESSION的任何更改；否则，只有具有新ID的会话将受到这些更改的影响。）window 'A' loads first and gets nonce 'P'
window 'B' loads second and gets nonce 'Q'
如果您无法跟踪多个窗口，那么您只能存储一个nonce-即B/Q窗口的nonce。当用户从A窗口提交其帖子并传递nonce“P”时，系统将拒绝该帖子，因为P != Q。
我没有阅读Shiflett的文章，但我认为你可能误解了一些内容。
默认情况下，当客户端不接受cookie时，PHP会在URL中传递会话令牌。否则，在最常见的情况下，会话令牌将存储为cookie。
这意味着，如果您将会话令牌放入URL中，PHP将识别它并尝试随后使用它。会话固定发生在某人创建会话，然后通过打开包含会话令牌的URL来欺骗另一个用户共享同一会话。如果用户以某种方式进行身份验证，则恶意用户知道已经经过身份验证的用户的会话令牌，后者可能具有不同的特权。
正如Shiflett所解释的那样，通常的做法是在用户特权更改时重新生成不同的令牌。
你可以通过在登录时重新生成会话ID来防止会话固定。这样，攻击者将不知道新认证会话的cookie值。另一种完全停止问题的方法是在运行时配置中设置session.use_only_cookies=True。攻击者无法在另一个域的上下文中设置cookie的值。会话固定依赖于将cookie值作为GET或POST发送。