的GUID，查询字符串和验证

我有一些在一些我已经构建的应用程序的位置，其中一个页面接受以下格式的查询字符串：然后http://localhost/MySite.aspx?ID=ab1cbabe-42e2-4d15-ab11-17534b829381的GUID，查询字符串和验证

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

实施例：

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

什么这显然意味着，任何用户（提供他们的GUID数据）可以在技术上访问任何其他用户的数据。显然，预测GUID几乎是不可能的，但我仍然对此感到不安。

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

来源

2011-08-08 Maxim Gershkovich

难道你不能使用普通的ASP.Net身份验证机制吗？ – Smudge202

我不是ASP.NET的专家，但是我有一些构建Web应用程序的经验。当某人复制粘贴电子邮件/ skype/etc中的链接时会发生什么？你为什么不使用会话？ –

显然我使用认证会话，但这不会影响问题。我们正在讨论一个经过认证的用户通过Guid，该用户对另一个用户帐户有效 - 虽然不太可能，但可以使用上述代码。 –

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

人们往往不洗去的查询字符串
大多数浏览器存储整个URI，包括历史查询字符串
大多数浏览器甚至还提供自动完成在地址栏，它可以让您张贴或发送电子邮件的URI试图通过已经访问资源
HTTP请求可以被几乎任何地方截获从客户端到服务器的方式，暴露了查询字符串

我recommen d某种基于用户的认证机制，如asp.net的成员资格提供者。

如果您已经在使用某种身份验证，则将资源GUID链接到关联表中的各自用户ID可能会起到一定作用。

来源

2011-08-08 12:03:16

你回答了自己的问题：“很显然，预测的GUID旁边是不可能的事”

然而，实现用户接入的正确方法，是建立和管理的ACL。你不能简单地依靠一个唯一的字符串，因为即使用户不猜测字符串，攻击者仍然可以嗅探流量并重新使用他们找到的GUID。

来源

2011-08-08 11:58:00

虽然你是正确的，但几乎不可能猜到某个GUID，猜测** a ** guid，并非 – sternr

这是正确的，我已经完成了我的答案。我猜他实施它的方式取决于他希望自己的资源有多安全。 –

我同意@Laurent。

但是 - 这取决于您的业务类型。对于诸如银行业务，金钱交易，敏感个人数据等极端安全相关的情况，我会去加密的cookie，或简单的 - 一个在查询字符串中传递的唯一密钥（正如您所问），但不是guid，但要更长一些（只要确保它的随机性很难预测），以及服务器上的一个后台任务，该任务会使超过X分钟的“令牌”失效，从而降低窃取URL的风险。

考虑采取一些标准的机制，如ASP.NET Membership。

来源

2011-08-08 12:02:48

的GUID，查询字符串和验证

回答

相关问题