时间戳

首页 > 解决方案 > 如何在 PHP 和 MySql 中保存和管理 Session ID 和 User ID

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

问题描述

我需要澄清我对PHP 会话的怀疑。

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

目前，我通过隐藏id的.PHPEditTextAndroid app

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

所以当我需要用户时，我从Facebook Account Kitid请求它，我得到它并通过一个隐藏字段将它发送到文件中，稍后我将在.PHPWHEREQuery

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

我的一个朋友告诉我，如果黑客获得了保存用户的id的，它可能已经过期并且他什么也得不到。sessionid

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

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

要将用户插入到ID我database应该始终将它从应用程序传递到PHP文件中，因此如果黑客可以发现用户id，我认为他可以很好地获取有关sessions子句的WHERE信息ID_user = ID_user。

完全正确？

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

然后，如果每次访问ID都Session更改了，要在数据库中的Sessions表中更改它，我应该再次从用户切换到用户并通过查询更新，我应该在子句中更改会话和访问日期。MySqlAndroid appPHPididID_User = ID_UserWHERE

精确的？

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

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

不管怎么说，还是要谢谢你。

标签： phpandroidmysqlsessionsession-variables

解决方案

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

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

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

  1. 第一次使用 $_SESSION 设置值时，PHP 会设置一个 Session 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 验证令牌（链接）
  • 验证 API 还返回用户信息，将其映射到您的用户数据（来自您的数据库结构）。

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

生成一个 UUID，创建一行

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

发送此 UUID 作为响应。

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

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

完全正确？

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

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

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

推荐阅读