Web 应用程序：在隐藏字段中存储 ID 安全吗？答案

【问题标题】：Web Apps: Storing ID in hidden fields safe?Web 应用程序：在隐藏字段中存储 ID 安全吗？
【发布时间】：2010-08-05 12:59:20
【问题描述】：

我只是有这个想法，但我不知道我是否慢。

通常，我将正在编辑的项目的 ID 存储在隐藏字段中。然后在后端（我正在使用 PHP/Zend 框架顺便说一句），我得到它来确定哪个项目被编辑。但后来我想，在更安全的地方，例如。编辑个人资料，用户可以以某种方式编辑隐藏字段吗？然后他可以编辑其他人的个人资料。我知道对于编辑配置文件，我可以从会话变量中获取 id，但是如果我得到一些需要我将 id 存储在某处的东西怎么办？

我有 ACL (Zend_Acl) 我这样做。基本上是从请求参数中获取id

$id = $req->getParam('id');

然后检查是否允许登录用户编辑该项目。但问题是我想知道网址是否类似于/users/edit/1，其中 1 是 id。但是不知何故，隐藏字段更改为2，请求参数是什么？

你会怎么处理？

【问题讨论】：

标签： php web-applications authorization

【解决方案1】：

您必须在客户端存储某种 id，否则您怎么知道要编辑哪个项目？
这不会使您从服务器上强制检查当前用户是否有权编辑/查看已编辑项目中解放出来。
除此之外，您为什么要关心他是如何编辑项目的（无论是通过合法使用网络工具，还是通过编辑隐藏/其他字段）。

【讨论】：

我想知道如果在 GET 和 POST 中都设置了 id 参数，我会得到什么值？将使用哪个？
当然，这取决于您实际拨打的电话。 $_POST 或 $_GET。然后，您可以选择使用哪一个，据我所知，以这种方式使用全局变量并不是一个好主意。
我认为只要我检查它就可以将 id 字段存储在隐藏字段中。我有 Zend_Acl。除了我使用$this->_getParam()，它似乎从 GET 和 POST 中获取参数。我刚刚测试过，当我在 GET 和 POST 中有不同的值时，我将从 GET 中获取。但总而言之，我认为只要我使用相同的方法获取 id 我就安全了？
使用某种 RESTful 框架，这个问题可以自行解决；正在编辑的记录的 ID 将包含在 URL 中。类似于对 /users/123 的 POST 请求

【解决方案2】：

将 ID 存储在隐藏值中并不是很安全。一般来说，我们将 ID 存储在 session 变量中。

【讨论】：

不需要使用会话变量。检查发布数据的用户是否有权编辑他们发布数据的记录，这在语义上更合理（也更容易）。
啊。 meagar，你把我想得很好！有 2 个变量应该存储相同的值，很混乱，可能容易出错
OP 正在询问如何确定正在编辑的记录是什么而不改变它，即他们如何存储 ID 然后回发到服务器以查询记录，因此 ppshein 的语句是正确的.您将 ID 存储在会话中，使其无法更改，然后检查该记录的权限。如果您不知道正在编辑什么文档，则无法检查权限。
@webnoob 我有时会同时打开几个带有多个答案/问题的 stackoverflow 选项卡。您可以看到，无需在空中循环，您的解决方案仅启用已编辑产品的一个打开窗口/选项卡。不是很用户友好。
@Italy Moav 好点。在那一点上，当然唯一真正的处理方法是存储在客户端使用的加密 ID，以便将其发送回服务器，因为任何存储它的方式服务器端都会导致相同的问题。非常感谢您对此提供反馈。

【解决方案3】：

正如 ppshein 所说，将敏感 ID 存储在隐藏的 var 中并不安全。您会将密码存储在隐藏的变量中吗？即使是新手黑客也很容易获得这些数据。

您需要确保所有访问控制都由服务器强制执行。

在您的情况下，您需要确保登录的用户（会话中的用户）是正在编辑的个人资料的所有者。或者进行编辑的用户有权编辑该配置文件（例如，是管理员）

【讨论】：

【解决方案4】：

不应基于用户提交的任何内容。您应该始终检查服务器端的用户权限。攻击者可以为您的服务器准备任何请求。

【讨论】：

【解决方案5】：

同意以上所有观点，但是如果您确实出于某种原因确实需要在客户端存储某些内容，您可以随时加密数据并在需要使用时解密，但同样，使用会话将是最好的处理方式因为它们无法访问客户端。

【讨论】：

这不会改变用户可以更改值的事实。
当然，这就是服务器端验证的用武之地。如果黑客更改了加密 ID 中的值，那么它将不再正确解密，因此您会知道有问题。跨度>
那么我认为在这种情况下加密可能不太有用，因为 id 不是秘密。加密与否，我仍然需要检查用户是否有权访问请求的资源。
关于您对@ppshein 帖子的评论，我认为我不能依赖可解密的哈希作为有效请求。如果不知何故，用户知道你的散列方法，他可以创建有效的散列来使用。
用户不会知道。这就是加密的重点（不是散列）。您有一个密钥存储在某个地方（或其他地方）的脚本中，并使用它进行加密和解密。您也可以使用不同级别的加密（最多 256 位（可能更多，不确定 - 从未更高:)）如果您需要在客户端显示某些内容，加密是最好的方法。