对于存在但用户没有足够权限(他们未登录或不属于正确的用户组)的网页,要提供的正确HTTP响应是什么?
401未授权?403禁止?还有别的吗?
到目前为止,我读到的每一篇文章都不太清楚两者之间的区别。每个响应都适合哪些用例?
对于存在但用户没有足够权限(他们未登录或不属于正确的用户组)的网页,要提供的正确HTTP响应是什么?
401未授权?403禁止?还有别的吗?
到目前为止,我读到的每一篇文章都不太清楚两者之间的区别。每个响应都适合哪些用例?
当前回答
假设正在使用HTTP身份验证(WWW-Authenticate和Authorization标头),如果以其他用户身份进行身份验证将授予对所请求资源的访问权限,则应返回401 Unauthorized。
403 Forbidden用于禁止所有人访问资源或限制访问给定网络或仅允许通过SSL访问资源,只要与HTTP身份验证无关。
如果HTTP身份验证未被使用,并且服务具有基于cookie的身份验证方案,这是现在的标准,那么应该返回403或404。
关于401,这来自RFC 7235(超文本传输协议(HTTP/1.1):认证):
3.1.401未经授权401(未授权)状态代码表示请求尚未应用,因为它缺少目标资源的有效身份验证凭据。源服务器必须发送一个WWW Authenticate头字段(第4.4节),其中至少包含一个适用于目标资源的质询。如果请求包括认证证书,则401响应指示已拒绝对这些证书的授权。客户端可以使用新的或替换的授权头字段重复请求(第4.1节)。如果401响应包含与先前响应相同的挑战,并且用户代理已经至少尝试了一次身份验证,则用户代理应该向用户呈现随附的表示,因为它通常包含相关的诊断信息。
403(和404)的语义随着时间而改变。这来自1999年(RFC 2616):
10.4.4 403禁止服务器理解该请求,但拒绝履行该请求。授权没有帮助,不应重复该请求。如果请求方法不是HEAD,并且服务器希望公开请求未完成的原因,则应在实体中描述拒绝的原因。如果服务器不希望向客户端提供该信息,则可以使用状态代码404(未找到)。
2014年,RFC 7231(超文本传输协议(HTTP/1.1):语义和内容)改变了403的含义:
6.5.3.403禁止403(禁止)状态代码表示服务器理解请求但拒绝授权。希望公开请求被禁止的原因的服务器可以在响应有效负载(如果有的话)中描述该原因。如果请求中提供了身份验证凭据,则服务器认为这些凭据不足以授予访问权限。客户端不应使用相同的凭据自动重复请求。客户端可以使用新的或不同的凭据重复请求。但是,由于与凭据无关的原因,请求可能被禁止。希望“隐藏”当前存在的禁用目标资源的源服务器可能会以状态代码404(未找到)进行响应。
因此,403(或404)现在可能意味着任何事情。提供新凭据可能会有所帮助。。。或者可能不会。
我相信这一变化的原因是RFC 2616假设在实践中,当今天的Web应用程序使用例如表单和cookie构建自定义身份验证方案时,将使用HTTP身份验证。
其他回答
我认为重要的是要考虑到,对于浏览器,401会启动一个验证对话框,让用户输入新的凭据,而403不会。浏览器认为,如果返回401,那么用户应该重新验证。因此401代表无效认证,而403代表缺乏许可。
以下是在这种逻辑下的一些情况,在这些情况下,验证或授权会返回错误,重要短语用粗体表示。
资源需要身份验证,但未指定凭据。
401:客户端应指定凭据。
指定的凭据格式无效。
400:这既不是401也不是403,因为语法错误应该总是返回400。
指定的凭据引用的用户不存在。
401:客户端应指定有效凭据。
指定的凭据无效,但请指定有效的用户(如果不需要指定的用户,请不要指定用户)。
401:同样,客户端应该指定有效的凭据。
指定的凭据已过期。
401:这实际上与通常的无效凭据相同,因此客户端应该指定有效凭据。
指定的凭据完全有效,但不足以满足特定资源的需要,尽管具有更多权限的凭据也可能。
403:指定有效凭据不会授予对资源的访问权限,因为当前凭据已经有效,但只有不具有权限。
无论凭据如何,都无法访问特定资源。
403:这与凭据无关,因此指定有效凭据没有帮助。
指定的凭据完全有效,但特定客户端被阻止使用它们。
403:如果客户端被阻止,指定新凭据将不会有任何作用。
根据RFC 2616(HTTP/1.1)403在以下情况下发送:
服务器理解该请求,但拒绝履行该请求。授权没有帮助,不应重复该请求。如果请求方法不是HEAD,并且服务器希望公开请求未完成的原因,则应在实体中描述拒绝的原因。如果服务器不希望向客户端提供此信息,则可以使用状态代码404(未找到)
换句话说,如果客户端可以通过认证访问资源,则应发送401。
我对它的看法与公认的答案略有不同。
当认证失败时返回403,当授权失败时返回401,这似乎更符合语义和逻辑。
我的理由如下:
当您请求认证时,您有权提出该请求。你需要这样做,否则一开始就没有人能够通过认证。
如果您的身份验证失败,您将被禁止,这是有意义的。
另一方面,被禁止者也可以申请授权,但假设您已通过身份验证,但无权访问特定端点。返回401 Unauthorized似乎更有意义。
对于失败的身份验证尝试,Spring Boot的安全性返回403
丹尼尔·欧文(Daniel Irvine)的明确解释[原始链接]:
401 Unauthorized(401未授权)存在问题,这是身份验证错误的HTTP状态代码。这就是它:它用于身份验证,而不是授权。收到401响应时,服务器会告诉你,“你不是已验证–完全未验证或已验证不正确–但请重新验证并重试。”为了帮助您,它将始终包含一个WWW Authenticate标头,描述如何以进行身份验证。这是通常由web服务器而不是web返回的响应应用这也是非常暂时的;服务器要求您尝试再一次因此,为了获得授权,我使用403 Forbidden响应。它是永久性的,它与我的应用程序逻辑有关,而且更具体响应大于401。收到403响应时,服务器会告诉你:“对不起,我知道你是谁——我相信你说的你是谁,但你只是没有访问此资源的权限。也许如果你问系统管理员很好,你会得到许可的。但请不要打扰直到你的困境改变。”总之,401未经授权的响应应用于缺失或认证错误,应使用403禁止响应之后,当用户经过身份验证但未被授权对给定资源执行请求的操作。
另一种很好的图片格式,说明如何使用http状态代码。
这是一个更老的问题,但一个从未真正提出过的选项是返回404。从安全角度来看,投票最高的答案存在潜在的信息泄漏漏洞。例如,假设所讨论的安全网页是一个系统管理页面,或者更常见的是,是一个用户无权访问的系统记录。理想情况下,您不希望恶意用户知道那里有一个页面/记录,更不用说他们无权访问。当我构建这样的东西时,我将尝试在内部日志中记录未经验证/未经授权的请求,但返回404。
OWASP提供了有关攻击者如何将此类信息用作攻击一部分的更多信息。