我是否应该在应用程序前端中模糊数据库主键 (id)

Question

我正在开发一个应用程序，该应用程序允许主持人编辑用户的信息。所以，目前，我有类似的URL

http://xxx.xxx/user/1/edit
http://xxx.xxx/user/2/edit

这里我有点担心，因为我直接暴露了数据库中的用户表主键（id）。我只是从URL中获取id（例如：上面URL中的1和2），用id查询数据库并获取用户信息（当然，我会对输入进行消毒，即从URL中提取id）。

请注意：

我正在验证每个请求，以检查主持人是否有权编辑该用户

这就是我正在做的。这安全吗？如果没有，我该怎么做？

我可以想出一个替代方案，即为用户表提供一个单独的列，其中包含25个字符的密钥，并使用URL中的密钥和带有这些密钥的查询数据库

但是，

• 这有什么区别？（由于密钥现在已公开）
• 按主键查询比其他列更快地生成结果

Answer 1

只要管理权限的验证是正确的，并且可以防止SQL注入，这是安全的（似乎是最好的方法）。这两件事你都提到了，所以我认为你很好。

Answer 2

基本问题是公开主键是否安全。我想说，在大多数情况下，它是安全的，我相信Stackoverflow也在以同样的方式进行：

http://stackoverflow.com/users/1/
http://stackoverflow.com/users/2/
http://stackoverflow.com/users/3/

如果你检查member for，你可以看到时间在减少，所以这个数字可能也是PK。

无论如何，在您希望普通用户只需在URL中键入1、2、3等即可避免浏览所有条目的情况下，隐藏PK可能很有用，在这种情况下，对535672571d2b4之类的内容隐藏PK是有用的。

Answer 3

如果你真的不确定，你也可以使用XOR和一个漂亮的（大的）固定值。这样你就不会暴露你的id。当对xor’ed字段再次应用相同的"秘密数字"时，将获得原始值。

$YOUR_ID异或$THE_SECRET_NUMBER=$OUTPUTTED_VALUE

$PUTPUTED_VALUE异或$THE_SECRET_NUMBER=$YOUR_ID

Answer 4

快速回答无

长应答

您有一个主键来标识某个人，它是唯一的。如果你添加了一个唯一的密钥来防止人们知道它，你就会知道他们知道另一个密钥。它仍然需要是唯一的，并且有一个索引（用于快速搜索），听起来很像主键。

如果这是一个不错的url的问题，那么你可以使用用户名或类似的东西。

但这将是一种默默无闻的安全感。因此，最好防止SQL注入并验证人们是否可以访问正确的操作

Answer 5

如果您有普通的自动递增id，您将向世界公开您的数据。这是不合理的（例如，对表中所有可用数据进行粗处理）。但您可以不按顺序生成DB实体的ID，而是以伪随机的方式生成。例如，在PostgreSQL中：

CREATE TABLE t1 (
    id bigint NOT NULL DEFAULT (((nextval('id_seq'::regclass) * 678223072849::bigint) 
    % (1000000000)::bigint) + 460999999999::bigint),
    ...
    <other fileds here>
)