3

这是我的情况：

我有一个从数据库中提取数据的搜索页面。显示的每条记录都附加了一个键，以便从数据库中提取该记录的数据。当单击记录文档的链接时，使用 KO 数据绑定将此键添加到 URL 上，并将控制权传递给相应的 MVC 控制器。

这是我的问题：

该密钥显示在 URL 中。我不能允许这样。本网站的用户只被允许访问某些记录。如果用户仅通过更改 URL 中键的最后一个或两个数字就可以看到任何记录，这是不可接受的。到目前为止，我想出的最佳解决方案是在处理搜索结果时使用 AES256 加密来加密每个密钥，然后在将加密传递给另一个控制器后解密。这很好用，除非我进入使用 HTTPS 的环境。我收到 400 个错误。

这是我想太多了吗？有没有办法使用 MVC 和 KO 完全屏蔽 URL 中的密钥？或者即使使用 HTTPS，也应该在 URL 中允许加密？

以下是一些澄清的例子：

如果不对我的代码进行任何更改，以下是 URL 的外观：

https://www.website.com/Controller/Method/1234

使用加密，我想出了这样的事情：

https://www.website.com/Controller/Method/dshfiuij823o==

只要它适用于 HTTPS，它就可以正常工作。

一种或另一种方式，我需要打乱 URL 中的密钥或摆脱它。或者确定每次调用控制器时不使用键运行搜索的方法。

谢谢大家的帮助。

4

2 回答 2

3

除非我在这里遗漏了一些非常明显的东西，否则你不能在 Web 服务方面检查登录用户是否对记录具有正确的权限，如果没有，不显示记录吗？

理想情况下，这应该在搜索级别完成，这样用户就不会看到任何他们无法访问的文件。即使他们更改了浏览器中的密钥，他们仍然无法访问。

如果没有会员系统，那么如果您真的想让您的网站安全，就需要实施一个。否则，你就是在玩火。否则，您将需要将文档设置为“公共”或“私有”，其中仍需要进行数据库级别的更改。

编辑

如果您确实需要使您的 ID 不可猜测，请不要对其进行加密，使用更简单的方法并在您的数据库级别为它们创建 GUID。然后您的 URL 将包含 GUID 而不是加密密钥。由于您不必在每次通话时加密/解密您的记录 ID，这将更加高效。

然而，这仍然不是 100% 安全的，我怀疑是否会通过 PCI 数据安全检查，因为人们仍然可以从查询字符串中查看（和复制/粘贴）GUID，就像使用加密字符串一样容易。实际上，您需要一个会员系统才能完全合规。

于 2012-10-19T16:04:02.347 回答
0

我同意狄克逊的观点。您应该检查用户是否有权查看任何项目。

我也同意使用 GUID 是个好主意。

但是，如果您不喜欢整数作为 id，这里有一个简单的方法：创建 URL 时：将 id 乘以一个大整数，例如 12345。然后在处理请求时，将 URL 中的数字除以您的“秘密” “ 数字。这不是万无一失的。但是一个猜测的人只有很小的机会获得一个真实的身份证——具体来说，12345 分之一的机会得到一个真实的身份证。

于 2012-10-19T16:15:11.940 回答