Question

我在许多应用程序中有许多位置，其中一个页面接受以下格式的QueryString：http://localhost/MySite.aspx?ID=ab1cbabe-42e2-4d15-ab11-17534b829381

然后，这些页面将获取查询字符串，尝试解析它并使用具有强类型值的数据库调用显示与guid匹配的数据。

示例：

Guid value;
if (Guid.TryParse(Request.QueryString["ID"], out value))
{
    SomeControl.Datasource = DatabaseCall(value);
    SomeControl.Databind();
}

这显然意味着任何用户（只要他们拥有数据的guid）在技术上可以访问任何其他用户数据。显然，预测guids是不可能的，但我仍然对此感到不安。

其他人如何处理这个问题？有“正确”的方式吗？它甚至值得担心吗？

Answer 1

在各种情况下，绝对值得担心。

人们倾向于发布或通过电子邮件发送URI，而不会删除查询字符串
大多数浏览器存储整个uri，包括历史记录中的查询字符串
大多数浏览器甚至在地址栏中提供自动填充功能，让您可以尝试浏览已访问过的资源
http请求可以在从客户端到服务器的任何地方截获，暴露查询字符串

我建议使用某种基于用户的身份验证机制，例如asp.net的成员资格提供程序。

如果您已经在使用某些身份验证，将资源guids链接到关联表中的各自用户ID可能会有所帮助。

Answer 2

你回答了自己的问题：“显然，预测guid是不可能的”

但是，实现用户访问的正确方法是构建和管理ACL。您不能简单地依赖于唯一的字符串，因为即使用户不猜测字符串，攻击者仍然可以嗅探流量并重用他们找到的GUID。

Answer 3

我同意@Laurent。

但 - 这取决于您的业务类型。对于极端安全相关的上下文，例如银行，货币交易，敏感的个人数据等，我会转到加密的cookie，或简单的 - 在查询字符串中传递的唯一键（如您所询问的），但不是guid但更长的东西（只是确保它的随机性很难预测），以及服务器上的后台任务使＃34;令牌失效＆＃34;超过X分钟，以减少窃取URL的风险。

考虑采用某种标准机制，例如ASP.NET Membership。

Guids，QueryStrings和身份验证

3 个答案: