当用户登录成功时，我将有一个user_id来访问会话。但问题是，在我分配后，用户/黑客是否可以修改？因为user_id我将用于查询和插入db并使用此user_id来执行所有查询。如果这是危险而不安全，我还能做些什么？谢谢。
答案 0 :(得分：4)
当你说你将有一个“user_id来访问会话”时，听起来你真的在谈论会话ID，而不是用户ID。基本上这是您在成功登录时设置的cookie，服务器使用cookie来查找正确的会话。
注意：会话劫持。使用会话ID是一种非常标准的方案（虽然它通常称为会话ID，而不是用户ID），但它实际上取决于它的实现方式。一般而言，您希望应用服务器自动为您处理此问题，而不必自己编写代码，因为有越来越不安全的方法来执行此操作。例如，如果会话ID是可猜测的，那么您的应用就容易受到所谓的session hijacking的攻击。显然你不希望ID成为一个序列，但这不是全部。你希望它们是随机的，你希望它们不具有模式（并不总是很容易看到 - 但是有确定是否存在模式的工具），你希望在生成会话ID时有足够多的比特在运行，通常，这是应用程序开发人员委托给支持基础架构的东西。
注意：会话固定。另一个风险是session fixation。有不同的变种，但基本概念是攻击者欺骗某人点击具有已知会话ID的链接（可以在URL中传递会话ID而不是使用cookie时完成）。例如，他可以在公共论坛中发布链接，然后受害者点击它并随后对会话进行身份验证。现在，攻击者可以接管会话，并且他已经过身份验证即可启动。一个对策是确保应用程序在从客户端收到无法识别的会话ID时生成新的会话ID，而不是简单地接受无法识别的会话ID并使用它开始新的会话。如果您使用标准机制来生成会话ID，那么很可能（尽管不能保证 - 查看您的文档）它已经提供了这种对策，至少是配置选项。如果你自己编写，那么非专业人士几乎肯定会忽视这一点。
识别会话和用户ID会导致会话被劫持。另一件事。如果您使用单个ID作为会话ID和用户ID执行双重任务 - 请不要这样做。首先，会话和用户在概念上是不同的东西（会话具有关联的用户，但它与用户不同），因此从纯建模的角度来看，它是不正确的。但更重要的是，用户ID通常不是秘密，它们会显示在URL（用户可以看到）之类的内容中。另一方面，会话ID绝对是秘密的。因此，例如，如果每次我登录您的应用程序时，您向我发送一个“user_id = 14”的cookie，那么所有人必须做的就是去查看您的应用程序，注意我是用户14，然后定期尝试通过您的应用的“user_id = 14”Cookie。迟早他们会在我实际登录的同时这样做，瞧，会话劫持。
答案 1 :(得分：-1)
你可以采取很多地方，但从表面上看。听起来不错。 许多站点将用户标识存储在cookie或会话对象中。您必须确保遵循最佳做法，以确保不会利用它。
如果您非常关注，可以随时加密。
德