2

从安全角度来看，我正在寻求有关使用 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={A guessed guid}”并且期望访问有效资源，包括使用脚本时每秒做出许多随机猜测？

或者，没有什么可以替代从 Session 变量中确定用户的 ID，确定他确实有权访问所请求的资源，然后才返回它（在我写这篇文章时，我越来越相信这种情况！ ）。

谢谢

4

3 回答 3

9

当然，除了验证用户并查看他们是否有权访问资源之外，没有其他替代方法。您在这里提出的是一种使用户更难为他们无权查看的文档（无论是错误的还是故意的）找到有效 ID 的方法。

GUID 肯定足够大，以至于您在实践中永远不会得到“意外”的有效 id。这使得未经授权的 GUID 会检查一个运行良好的系统，只要没有人积极尝试破坏它。另一方面，授权检查是一个即使在有活跃攻击者的情况下也能很好地工作的系统（当然这取决于攻击者可以设法做什么）。

您应该根据应用程序的性质在两种方法之间进行选择（它是公开的吗？用户是否知道并对他们的行为负责？“安全漏洞”会有多严重？）。

于 2013-02-21T11:33:37.073 回答
6

如果它是受保护的内容，您应该在盲目地提供用户之前确定用户是否被授权。

GUID 确实在一定程度上有所帮助，它使猜测 URL 变得更加困难，所以我仍然建议使用它们。但是 URL 仍然可以共享（即使是偶然的）。如果不管是谁提出请求，您都只是要提供内容，那么它几乎没有真正的保护。

于 2013-02-21T11:33:27.770 回答
0

如果您认为内容受到限制并且有一些个人数据，那么您应该使用用户名和密码。

于 2013-02-21T11:35:14.740 回答