MVC / REST是否应为属于其他用户的资源返回403或404？

当使用基于资源的站点（例如MVC应用程序或REST服务）时，当客户端尝试GET访问他们无权访问的资源时，我们有两个主要选择：

• 403，表示客户未经授权 ; 要么
• 404，表示资源不存在（或无法找到）。

共同的智慧和惯例似乎是对事实做出回应-即403。但是我想知道这是否真的是正确的做法。

安全登录系统永远不会告诉您登录失败的原因。也就是说，就客户端而言，不存在的用户名和错误的密码之间没有可检测到的差异。目的是使用户ID（或更糟糕的是电子邮件地址）不易被发现。

从隐私的角度来看，返回404似乎更安全。我想起了一起事件，据说有人通过查看真人秀（幸存者）中的哪些资源不存在而找到了他们。网站与哪些网站做了。我担心403可能会泄露敏感信息，例如序列号或帐号。

是否有令人信服的理由不返回404？404政策会在其他地方产生负面影响吗？如果没有，那为什么不更普遍呢？

有一个与之相关的普遍误解（和误用）403 Forbidden：不应泄露服务器对请求的看法。它是专门为说，

我能满足您的要求，但是无论您尝试什么，我都不会处理。因此，请停止尝试。

任何UA或客户应将其解释为意味着该请求将永远无法工作，并做出适当的响应。

这对客户端代表用户处理请求的含义是：如果用户未登录或输入错误，则处理请求的客户端应在第一时间后回复“对不起，但我无能为力”它获取403并停止处理将来的请求。显然，如果您希望用户在失败后仍然能够请求访问其个人信息，则这是对用户不利的行为。

403是相反的401 Authorization Required，这不放弃服务器处理请求，只要你通过正确的凭据。这通常是人们听到声音时会想到的403。

404 Page Not Found正如其他人所指出的，它也与之相反，该设计不仅被设计为说“我找不到该页面”，而且还向客户端建议服务器不为将来的请求声明成功或失败。

使用401和404，服务器不会对客户端或UA透露任何处理方式：他们可以继续尝试，以期获得不同的响应。

因此404，处理不希望显示给所有人的页面的合适方法是，您不想放弃任何在某些情况下为什么不显示页面的信息。

当然，这假设发出请求的客户端关心小巧的RFC冗余。足够恶意的客户端将不会关心返回的状态码，除非是偶然的方式。通过将其与其他已知用户页面进行比较，就会知道它是一个隐藏用户页面（或潜在的隐藏用户页面）。

也就是说，假设您的处理程序是users/*。如果我知道users/foo，users/bar和users/baaz工作中，服务器返回401，403或404为users/quux不意味着我不打算尝试一下，尤其是如果我有理由相信是一个quux用户。一个标准的示例场景是Facebook：我的个人资料是私人的，但我对公开个人资料的评论不是。即使您返回404我的个人资料页面，恶意客户端也会知道我的存在。

因此，状态码不是针对恶意用例的，而是针对遵循规则的客户端的。对于那些客户，一个401或一个404请求是最合适的。

根据RFC2616

10.4.4 403禁止

服务器理解了该请求，但拒绝执行该请求。授权将无济于事，并且不应重复该请求。如果请求方法不是HEAD，并且服务器希望公开为什么未满足请求，则应在实体中描述拒绝的原因。如果服务器不希望将此信息提供给客户端，则可以改用状态代码404（未找到）。

还请注意，访问禁止资源时，授权无济于事。

你应该？是的。

你自己说的，尽量少出卖。如果我正在攻击系统，并且注意到服务器以403代码作为响应，则我将重点放在这些代码上，而不是继续前进。最好一扇门宣布它不存在，然后宣布它被禁止。

使用404请求的不利之处在于，它在外部看起来像该页面不存在，并且与应该存在但缺少的页面相比，这可能会有冲突。如果您不担心Web爬网程序（无论如何都应完全拒绝经过身份验证的系统），那么绝对应该这样做。我处理的每个API都以完全相同的方式处理未经授权的访问，StackOverflow也是如此。看不到该页面？我向您保证它确实存在，即使它声称不存在。

当已知资源存在并且访问被拒绝时，您应该确认请求。登录失败不应导致404消息。当资源本身的存在应受到保护时，您不应确认请求。对领域的访问存在于公共场所，但其中不存在安全组或角色。

令人信服的理由不返回404：如果服务关闭或身份验证中存在错误/错误，那么您会得到404，但是尝试诊断问题的客户/用户/测试人员/开发人员/支持人员可能不知道错误消息出了什么问题

开发人员应该有权访问日志，这将表明尝试访​​问受保护的资源。客户/用户/测试人员将生成反馈，最终反馈给开发人员。

默默无闻的安全...真的吗？

这不是默默无闻的安全措施。除了适当的安全措施之外，您还使用了模糊处理。

另一方面，获得“ 404”的有效请求只会增加不必要的复杂性和模糊性

它们不是有效的请求，它们是未经授权的请求。您只需更改一小部分（返回404而不是403）即可在任何可能的攻击者中获得实质性的优势。

这实际上取决于403状态代码给出的信息。如果您有一个API端点，GET /myresource/{id}当资源不存在时响应404，则当资源存在但未被当前用户授权时，端点返回的状态代码应取决于id参数的可预测性以及数量本身包含的信息。

• 如果id是一个私有字段，例如电子邮件地址或银行帐号，则可能始终应将其隐藏在404后面。如果是电子邮件地址，它可能会阻止垃圾邮件程序漫游器编译已注册到您网站的有效电子邮件地址列表。
• 如果id是公共用户名，请不要打扰，还有其他方法可以访问此信息（例如，仅通过浏览网站的论坛页面即可）。
• 如果id是不透明但可预测的标识符（例如，一个自动递增的整数），则不会向攻击者泄露任何其他方式无法获得的信息。因此，我认为返回403状态代码是安全的。
• 如果id是不透明且不可预测的标识符（如随机GUID），则问题会更加微妙。我个人认为返回403状态代码没有问题。仅当使用此ID的API中存在另一个有缺陷的端点时，才能利用此信息，但真正的缺陷是您的另一个端点。

在任何情况下，您可能都认为安全胜于遗憾，并且不管上下文如何都隐藏信息，但实际上您不能依靠这种类型的行为来提供任何形式的安全性。另一方面，它可以提供机密性（或隐私，就像其他人所说的那样）。

安全机制不应该只是攻击者的减速机，否则就毫无用处。在这种情况下，它甚至可能阻止您正确使用其他功能（爬网程序，Web应用程序防火墙正在寻找异常数量的403状态代码以阻止用户...）。