如何在 PHP 和 MySql 中保存和管理 Session ID 和 User ID

Question

我需要澄清我对 PHP sessions 的疑虑。

我正在创建一个Android app，在某些活动中我需要进行查询以提取用户数据。

目前，我通过Android app 中的隐藏EditText 将用户id 发送到PHP 文件。

在Android app 中，用户id 未保存在shared preferences 中，但我通过对Facebook Account Kit 的请求获得它（用于身份验证Facebook Account kit）。

所以当我需要用户id 时，我从Facebook Account Kit 请求它，我得到它并通过一个隐藏字段将它发送到PHP 文件，稍后我将在WHERE 子句中使用它Query.

但是，现在，出于安全原因，我更愿意使用sessions 来保存用户id，然后将用户id 保留在session 中。

我的一个朋友告诉我，如果一个黑客获得了session 的id，其中保存了用户id，它可能已经过期并且他无法获得任何东西。

问题是我不明白如何保存session ID 和userID 以及如何在database 表架构级别管理它们。

我必须将session ID 保存在database 中，我创建了一个名为“Sessions”的表，其中包含 3 个字段：

• Session_ID，
• ID_User，
• 数据访问。

要在database 上插入用户ID，我应该始终将其从应用程序传递到PHP 文件，因此如果黑客能够发现用户id，我认为他很可能会得到有关sessions 的信息，带有WHERE 子句ID_user = ID_user。

对吗？

如果我是对的，那么有什么比我做的更安全的呢？

然后，如果Session 的ID 随每次访问而更改，要在MySql 数据库中的Sessions 表中更改它，我应该再次从Android app 切换到PHP 用户@ 987654364@ 并通过查询更新我应该在WHERE 子句中使用ID_User = ID_User 更改会话id 和访问日期。

准确吗？

如果有人对我有任何建议或批评我如何处理这种情况并有比我更好的解决方案，我愿意倾听。

如果我对课程的运作方式一无所知，请提前原谅我偷了你的时间。

还是谢谢。

Answer 1

PHP 会话基于 Cookie。当用户打开网页时，PHP 会设置一个 cookie 作为响应。浏览器自动确保在后续请求中，该 cookie 也会在请求中发送，因此 $_SESSION 变量有效。在我看来，它们并没有提供太多的安全性。现在，恶意用户必须获得 Cookie，而不是用户 ID。 始终使用 HTTPS 来保护请求。

使用 Android 应用，您将发出自定义请求，因此您必须明确设置 cookie，一旦从第一次调用中收到（您必须将其保存在客户端；不是好方法）。

会话通常的工作方式如下-

1. 第一次使用 $_SESSION 设置值时，PHP 会设置一个会话 cookie，它本质上是一个随机字符串。
2. 在后台（在后端），PHP 正在针对该字符串值维护一个对象（键值对）。 （SessionKey1 = { key: value, key2: value2 }；这可能位于磁盘文件系统或缓存层（例如 Redis）上，具体取决于您的服务器配置）
3. 当您在会话中设置/更新/删除密钥时，SessionKey1 会被修改。

现在您可以为自己创建类似的行为。在Android App端找到userId后，将其发送到后端，在会话表中创建一行（Session Id为随机字符串，UserId为UserId）。随着每个请求发送此 SessionId 以及请求（在正文或标头中），在后端检查 sessionId 是否在 Sessions 表中收到退出。如果是，获取用户 ID 和进程。

这是另一种方法（可能更安全一些）

Account Kit验证后发现Access Token时

• 发送到后端
• 从 Facebook API (Link) 验证令牌
• 验证 API 还返回用户信息，将其映射到您的用户数据（来自 您的数据库结构）。

（这将确保令牌始终有效，用户将无法放置随机令牌进行攻击，因为这将无法通过 Facebook API 的验证）。

生成一个 UUID，创建一行

• UUID 作为 sessionId，
• 您的用户 ID
• 访问数据
• 创建于（创建行时）
• 到期（当前时间 + X 天）

发送此 UUID 作为响应。

现在在 Android 端，将此 UUID 保存在某处。创建一个请求拦截器，为所有请求在自定义标头中设置此 UUID（例如X-<application_name>-Auth）。在每个请求的后端，访问此标头，检查它是否已过期，从会话表中获取用户 ID，然后继续。

我认为他可以很好地获取有关带有 WHERE 子句 ID_user = ID_user 的会话的信息。

对吗？

你完全正确。但是，保护 DB 层应该是与应用程序开发分开的任务。你认为黑客如何能够首先执行查询？如果有人找到一种在 DB 上运行原始查询的方法，他可能会造成比仅仅提取数据更大的损害。

如果我是对的，那还有什么比我做的更安全？

没有正确的答案，您只需要尽力保护应用程序即可。确保您的应用程序遵循最佳安全实践。例如 - 使用 HTTPS，防止 SQL Injection.s（搜索 OWASP Vulnerabilities）