会话劫持导致令牌暴露答案

【问题标题】：Session hijack resulting in token exposure会话劫持导致令牌暴露
【发布时间】：2011-12-19 20:57:03
【问题描述】：

我正在努力解决会话劫持和使用令牌进行 CSRF 保护的问题。我在每个脚本中都使用此对象方法来检查是否设置了会话变量或令牌是否与会话令牌匹配。

public function admin_index(){

session_start();
if(!isset($_SESSION["user"]) || $_GET['token']!=$_SESSION['token']) {
    header("location: login/login_form.php");
    session_destroy();
    exit();
}

我是新手，我的问题是：如果我的会话 ID 以某种方式被劫持，他是否能够在 session_start 之后的短时间内读取我的变量 $_SESSION['token'] 并且会话数据被获取并填充到 $_SESSION 中，或者它仍然安全吗？服务器？

即使已获得有效会话，会话变量通常是否安全？

不要介意 $_GET['token'] 而不是 POST。我还在努力。

谢谢

编辑：

我要问的是。如果令牌还可以帮助我以我使用它的方式保护我的会话。如果我的脚本中的每个查询、链接或视图都需要一个有效的令牌，并且攻击者只获得了我的 session_id，那么令牌将是另一层保护，因为他/她需要 id 和令牌才能在脚本中执行任何操作对吧？

即使攻击者获取了我的 session_id，令牌在服务器上也是安全的？

【问题讨论】：

重申一下，如果您的会话被劫持，则 csrf 没有价值。希望这很清楚。它无助于会话劫持或防止会话劫持。通常有帮助的是检查用户代理和/或 IP 地址的更改，当然最终的安全性是 https: 和安全 cookie。
这无助于保护您的会话，因为每次访问表单时都会生成 CSRF 令牌。因此，如果我劫持了您的会话并使用您的帐户访问该表单，则会生成一个新令牌，并且无论之前的 CSRF 令牌是什么，我都可以做我喜欢的事情。
在您的示例中是匹配对令牌的更改或用户是否已通过身份验证。您应该只使用令牌来检查数据是否来自受信任的来源。您似乎将其用作不太正确的辅助会话 ID。如果您从用户的唯一标识符（例如 session_id 和浏览器的 User-Agent）创建哈希，则可以这样做，因为每次都可以检查。

标签： php session token

【解决方案1】：

会话劫持和 CSRF 攻击是完全不同的两件事，一旦有人可以访问您的会话，他们就是“您”，可以访问您帐户中的所有内容。

CSRF 攻击是一种强制最终用户执行的攻击在他/她当前所在的 Web 应用程序上执行不需要的操作已认证

这是一个社会工程和验证问题，使用令牌显然可以解决，因为可以证明数据是从您的表单合法发送的。使用 POST 而不是 GET 将使这种攻击变得非常困难。

另一方面，会话劫持是有人可以使用您的会话，成为“您”并使用您的帐户，这将允许他们做随心所欲。

一旦恶意用户有权访问此会话，CSRF 攻击就几乎没有用处，因为它是不需要的。

如果您担心您的会话 ID 被劫持，那么您可以采取一些预防措施，例如在用户提升到更高访问级别后重新生成用户会话 ID。这可以使用 session_regenerate_id() PHP 函数来完成。您还可以检查浏览器的用户代理以检查是否有更改，如果有，您可以简单地要求用户登录并重新生成 id，以便攻击者不知道它。显然，他们总是有可能成为同一个用户代理，但这确实大大限制了风险。 SSL/HTTPS 等加密也是您可能想要查看的选项

有关更多信息，您应该查看此链接以获取一些示例：http://phpsec.org/projects/guide/4.html。希望这已经解决了你的问题:)

【讨论】：

嗨，丹尼尔，它对我帮助很大。我以前看过那个文件。我阅读了另一篇文章，它解释了我尝试做的令牌系统。你怎么看呢。第 49-50 页：phpsecurity.org/ch04.pdf 我猜它只有在 cookie 被盗时才有效，因此攻击者只有 session_id。如果攻击者嗅探 http 请求，他将同时拥有令牌和 id。我也实现了会话重新生成。我只是认为这可以作为额外的安全措施。
是的，我在过去的一个项目中实现了一个类似的会话劫持令牌，它使用了类似的东西。然后可以将此检查合并到您的代码中，以检查用户是否经过身份验证。 cookie 被盗的主要原因是 XSS 漏洞利用，因此请确保在输出中使用 htmlentities()，但也要进行足够的验证和清理检查，这就足够了。

【解决方案2】：

会话变量存储在服务器上。它们无法读取。但是，攻击者通常可以劫持会话，该攻击者可以访问另一个用户的会话 ID，然后可以使用该会话 ID 来冒充（劫持）他们的会话。

CSRF 是一个完全不同的问题。 CSRF 漏洞让用户无意中以类似于 xss 漏洞的方式执行操作：我可能会发布一个虚假的 img 链接，其中 src 实际上是一个 url，它将参数传递给您的浏览器代表您运行的脚本。在这种情况下，攻击者只是让您的浏览器发出您不希望它发出的请求。 CSRF 保护应该阻止这种情况，因为用户不知道令牌是什么，所以他们不能将其嵌入到 url。

【讨论】：

嗨，gview，谢谢，但如果攻击者获取了我的会话 ID，但我脚本中的每个操作都需要一个令牌才能执行。令牌不仅可以保护我免受 CSRF 的侵害，还可以保护我免受劫持，对吧？因为他需要会话 ID 和令牌，令牌存储在会话中。
不，因为如果您的会话被劫持，攻击者只会生成新的表单来泄露令牌。令牌是您在服务器上生成的秘密，并以表单或 url 参数的形式提供。它只会阻止没有会话的人欺骗有会话的人执行他们不打算执行的 get 或 post 请求。
hmm...但是如果在我的所有脚本上运行上述脚本，如果令牌丢失，您将无法访问表单。我将令牌附加到所有链接而不仅仅是表单，因此即使您拥有正确的 session_id，如果没有令牌，脚本中也不会起作用。在拿到表格之前，您将被踢出局。我从这个 pdf 第 49-50 页得到了这个想法：phpsecurity.org/ch04.pdf。很抱歉一直打死马;-)

【解决方案3】：

如果我错了，请纠正我，但我很确定您根本无法劫持 $_SESSION 值，因为这些值与 $_COOKIE 不同，保存在服务器上而不是网络浏览器中。

因此他们也无法改变它。他们可以关闭他们的网络浏览器来删除它，但不能编辑它。

【讨论】：

谢谢罗宾。这也是我所希望的。所以我猜想检索会话变量的唯一方法是它是否通过 php 脚本将 f.ex 回显到浏览器。如果这样的脚本不存在，它是否安全？
如果我劫持了你的会话，我就是你。我可以做任何你做的事情，CSRF 是无关紧要的。我已经在你的帐户中了。
但是如果你刚刚从 f.ex 获取了会话 id 的 http 头，但是每个查询都需要一个隐藏在 session_id 中的令牌。令牌可以保护我免受完全劫持，对吗？攻击者需要同时拥有会话 ID 和令牌？
会话 ID 将您与会话联系起来。维护此关联的推荐方式是 cookie。如果我拦截了那个 cookie，这就是我可以轻松劫持您的会话的方式。走进咖啡馆，跳上 wifi，然后通过 http 登录到他们最喜欢的网站的人，是那些将自己暴露在会话劫持中的人，更不用说任何使用 wifi 或与他们无法访问的人共享网络的人相信不要嗅探他们的数据包。
啊，好吧，如果我在嗅探网络上。我的 session_id 和令牌（作为 GET）将在对服务器的请求中可见，而不仅仅是 session_id？ ssl 连接能解决这个问题吗