通过URL传递GUID的安全风险

3
我需要一些关于GUID在安全方面使用的建议。我开发了一个ASP.Net应用程序,它为用户提供访问一些不在Web服务器上的材料,如文档和照片,这些材料存储在文件服务器上。我有一个“GetResource.aspx”页面,它接受资源的ID,使用System.IO.FileInfo打开它,将其写入响应流并返回它。
因此,“GetResource.aspx?id=123”会返回用户可以访问的图片。当然,用户也可以手动输入URL“GetResource.aspx?id=456”,在这种情况下,具有该ID的图片/文档等将被返回,但他们可能没有权限访问它。
因此,明显使用整数ID是不够的。使用GUID作为ID是否提供足够的“随机性”,使我可以可靠地假设用户永远无法手动输入“GetResource.aspx?guid={猜测的guid}”并期望访问有效的资源,包括使用每秒进行多次随机猜测的脚本?
还是说没有替代方法,只能从Session变量确定用户的ID,确定他确实可以访问所请求的资源,然后才返回它(当我写这篇文章时,我越来越相信这是正确的方法!)。
谢谢

谢谢Kobi,我之前没有看到过,同意它们很相似。也感谢所有回答的人,非常有帮助。 - Kate
3个回答

10
确保用户身份并检查其是否有权访问资源是无可替代的。你在这里提出的方法是使用户更难以获取他们未被授权查看的文档的有效ID(无论是错误还是故意)。GUID足够大,以至于在实践中您永远不会获得“意外”的有效ID。这使得没有授权检查的GUID成为一个系统,在没有人积极尝试破坏它的情况下运作良好。另一方面,授权检查是一个即使在存在积极攻击者的情况下也能正常工作的系统(当然这取决于攻击者能够做到什么)。根据应用程序的性质(它是否公开?用户是否已知并对其行为负责?“安全漏洞”有多严重?),您应该选择两种方法之一。

谢谢Jon,这是一个非常平衡的回答,提出了一些很好的观点,包括意外和有人故意破坏之间的区别。 - Kate

6

在提供受保护的内容之前,您应该确定用户是否已被授权。

GUID 在一定程度上确实有帮助,它可以使 URL 猜测更加困难,因此我仍然建议使用它们。但是 URL 仍然可能会被共享(甚至是意外共享)。如果您只是无论谁请求都会提供内容,那么它就没有真正的保护作用。


0
如果您认为内容受限且包含某些个人数据,则应使用用户名和密码。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接