保持用户特定会话信息安全的最佳方法答案

【问题标题】：Best way to keep user specific session info secure保持用户特定会话信息安全的最佳方法
【发布时间】：2014-01-18 04:14:52
【问题描述】：

我使用 PHP/MySQL 开发了一些东西。架构是这样的，每个用户都有自己的（不同的）数据库名称，在该数据库中，每个人都调用相同的表。所以基本上，如果“坏”用户可以将他的数据库名称切换到其他人 - 他可以访问某人的数据意味着安全受到破坏。

保存此类用户特定数据的最佳方式是什么，例如在我的情况下是他的数据库名称？
但我想答案将是 $_SESSION superglobal ？如果是这样，它有多安全？用户（仅限http）可以更改存储在$_SESSION 中的变量的值吗？特别是如果我在那里保留简单的 db_name ？或者，如果我对此感到偏执，我应该散列那个 db_name -> 将其保留在会话中 -> 读取它 -> 在服务器端取消散列 -> 给用户他的数据库？如果有什么好的建议我可以使用什么加密/解密？（我不知道）

很多问题，但都非常狭窄 - 提前谢谢您！

编辑：恐怕我没有正确解释自己：

不同的数据库（或数据库名称）是指相同的 MySQL 实例，只是内部的不同数据库（如 SQL 语言中的 CREATE DATABASE "sec_login"; USE "sec_login";），例如，我将拥有以下数据库：

sec_login（包含表：成员、loging_attempts 等）
...
db_user1
db_user2
...
db_user1001

所以每当例如user2 登录它会在 user1001 来到$db_name = db_user1001; 时得到他的$db_name = db_user2;，然后程序将为他们提供与这些数据库中的表相同的逻辑。

所以是的，我的问题是在这种情况下，$db_name = db_user2; 的值应该保存在哪里
谢谢@Nathan Hazout 我得到了你关于$_SESSION 被保存在哪里的答案。并感谢一个很好的链接！有用并为第二次阅读添加书签:)

关于安全：我完全同意“……尽你所能”。但只是想知道“坏”用户可以访问其他人的$_SESSION 的可能性有多大。如果我错了，请纠正我 - 在$_SESSION 中窃取其他变量与窃取其他 session_id 相同，对吧？

【问题讨论】：

each user will have own (different) DB name, 一个非常糟糕的设计！改变它！
我认为您的问题第一次就被很好地理解了。让一个 MySQL 实例只运行一个数据库。将您将在多个数据库中拆分的所有成员放在一个 members 表中，然后添加一个外键来存储所有权。不幸的是，您提出的设计会让您陷入困境！

标签： php mysql session

【解决方案1】：

存储在$_SESSION 变量中的数据将保留在您的服务器上，而不是在 cookie 中，如果您担心的话。存储在客户端的只是一个会话 ID，一种标识符，因此您的服务器将知道要加载哪些 $_SESSION 数据。

参见例如Is my understanding of PHP sessions correct?

话虽如此，您的代码只有在您编写时才是安全的。

我不会详细介绍“每个用户都有自己的（不同的）数据库名称”，我只是不明白您对架构的选择......

【讨论】：

感谢您的回答。请阅读我上面的Edit，希望我能澄清一下。
我第一次明白。我仍然不明白你为什么需要这个。这不是很标准。通常您将所有内容存储在同一个数据库中，并且只提供用户需要的内容。就安全性而言，我认为会话已经足够了。
也许使用不同的数据库可以让 SELECT 更快？可能保持数据限制会更容易（当遇到问题时）。我不知道，只是寻找已经实施的方法的优势。出于一些未知的原因设计它，我没有采用这种方法作为一种选择。但可能真正的原因是我现在想专注于用户功能 :) 并且没有考虑很多选项来获得全局 :) 谢谢您的回复 - 我会选择 SESSION，因为它只保留在服务器端。

【解决方案2】：

如果你添加一个用户表，任何可以被用户拥有的实体都可以得到一个user_id 外键。我听说一些金融公司坚持使用分离的数据库（出于偏执的安全原因），但总的来说，拥有一个数据库是一个更好的主意。这意味着提取系统范围的元信息（例如“哪个用户正在执行最多的事务？”）要容易得多 - 如果您有单独的数据库，您可能无法在表之间进行必要的连接。

一般来说，用户没有能力改变$_SESSION超全局的内容，但是你需要检查你的代码没有给他们那个能力！因此，我不会为散列的事情烦恼（而且，从技术上讲，没有取消散列这样的事情 - 你可能正在考虑加密）。

【讨论】：

感谢您的回答。事实上，它是相同的数据库 - 所以我可以进行 JOIN 等操作...只是使用不同的 USE db_1 或 USE db_2...
是的，我显然在谈论加密。我编辑了上面的帖子。
“它是同一个数据库”，我认为你的意思是“它是同一个服务器”——如果你用USE 切换数据库，那么它们必须是不同的数据库。所以是的，我的答案是只有一个数据库，只有一个 USE 值。
Oki 似乎该术语现在已修复:) 不能真正证明我在一个数据库服务器上使用不同用户拥有的数据库的方法更好（也许这使我能够限制用户数据库的大小.. .如果以后它很重要）也不确定（也许更容易放弃用户，但这没关系）不确定。但是我的程序的功能逻辑已经构建并且构建方式是每个新用户都可以获得新的干净数据库并用自己的数据填充那里的表。你预见到它有什么大问题吗？可能是什么时候我想在一些主机上托管它？安全方面 - 用户不应该知道他的数据库的名称...
最大的问题是它比它需要的复杂得多。的确，您可以在 MySQL 中进行跨数据库连接，但实际上，您的方法为您提供了复杂性，但几乎没有优势。就我个人而言，我会将你所拥有的一切都投入到版本控制中，然后重构，使其仅适用于一个数据库。

【解决方案3】：

我猜你有你的理由让每个用户使用不同的数据库，我认为我从未听说过这种架构。无论如何，不要在会话中存储数据库名称，存储一些标识用户的哈希值，在一个通用数据库上保存一个用户表，当用户登录时，将他当前的会话 ID 放在这个用户表中，这样当用户给你会话 ID 时，您从此表中获取数据库名称。很难猜测会话 id 会导致其随机字符序列。

【讨论】：