security - 在 session 中存储 user_id 是否危险？

Question

当用户登录成功时，我将有一个 user_id 来访问 session 。但问题是用户/黑客可以在我分配后进行修改吗？因为我将使用 user_id 来查询和插入 db 并使用此 user_id 来执行所有查询。如果这是危险的而不是安全的，我还能做什么？谢谢你。

Answer 1

当您说您将有一个“访问 session 的用户 ID”时，听起来您实际上是在谈论 session ID，而不是用户 ID。基本上，这是您在成功登录时设置的 cookie，服务器使用 cookie 查找正确的 session 。

当心: session 劫持。 使用 session ID 是一种非常标准的方案(尽管它通常称为 session ID，而不是用户 ID)，但它实际上取决于它是如何实现的。通常，您希望应用程序服务器自动为您处理此问题，而不必自己编写代码，因为有越来越多的安全方法可以做到这一点。例如，如果 session ID 是可猜测的，那么您的应用程序很容易受到所谓的 session hijacking 的攻击。 .显然，您不希望 ID 是一个序列，但这还不是全部。你希望它们是随机的，你希望它们没有模式(并不总是很容易看到——但有工具可以确定是否有模式)，你希望在生成 session ID 时有足够多的位在起作用，等等。通常这是应用程序开发人员委托(delegate)给支持基础设施的东西。

当心: session 固定。 另一种风险是session fixation .有不同的变体，但基本概念是攻击者诱骗某人单击具有已知 session ID 的链接(当 session ID 在 URL 中传递而不是使用 cookie 时，可以做到这一点)。例如，他可能会在公共(public)论坛上发布链接，然后受害者单击它并随后验证 session 。现在攻击者可以接管 session ，并且他已通过身份验证启动。一种对策是确保应用程序在从客户端接收到无法识别的 session ID 时生成新的 session ID，而不是简单地接受无法识别的 session ID 并与它开始新的 session 。如果您使用标准机制来生成 session ID，那么很有可能(尽管不能保证 - 查看您的文档)它已经提供了这种对策，至少作为配置选项。如果您自己编写，那么非专家几乎肯定会忽略它。

识别 session 和用户 ID 会导致 session 劫持。 另一件事。如果您使用单个 ID 来执行 session ID 和用户 ID 的双重职责，请不要这样做。首先， session 和用户在概念上是不同的东西( session 有一个关联的用户，但它与用户不同)，所以从纯建模的角度来看，它是不正确的。但更重要的是，用户 ID 通常不是 secret ，它们会出现在 URL 之类的东西中(用户可以看到)。另一方面， session ID 绝对是 secret 的。因此，例如，如果每次我登录您的应用程序时，您向我发送一个显示“user_id=14”的 cookie，那么有人要做的就是查看您的应用程序，注意我是用户 14，然后定期尝试通过一个“user_id=14”cookie 到您的应用程序。迟早他们会在我实际登录的同时这样做，瞧， session 劫持。