对于存在但用户没有足够权限(他们未登录或不属于正确的用户组)的网页,要提供的正确HTTP响应是什么?

401未授权?403禁止?还有别的吗?

到目前为止,我读到的每一篇文章都不太清楚两者之间的区别。每个响应都适合哪些用例?


当前回答

考虑到最新的RFC(7231和7235),用例似乎非常清楚(添加了斜体):

401表示未经认证(“缺少有效认证”);即“我不知道你是谁,或者我不相信你是你说的那样。”

401未授权

401(未授权)状态代码表示请求没有已应用,因为它缺少有效的身份验证凭据目标资源。生成401响应的服务器必须发送WWW Authenticate头字段(第4.1节),至少包含一个适用于目标资源的挑战。

如果请求包括认证证书,则401响应表明授权已被拒绝资格证书用户代理可以使用新的或替换了Authorization头字段(第4.2节)。如果401响应包含与先前响应相同的挑战用户代理已经至少尝试了一次身份验证,然后用户代理应向因为它通常包含相关的诊断信息。

403表示未经授权(“拒绝授权”);即“我知道你是谁,但你无权访问此资源。”

403禁止

403(禁止)状态代码表示服务器已理解请求,但拒绝授权公开为什么该请求被禁止可以描述这一点响应有效载荷中的原因(如果有的话)。

如果请求中提供了身份验证凭据服务器认为它们不足以授予访问权限。客户不应自动重复相同的请求资格证书客户可以用新的或不同的重复请求资格证书然而,出于某些原因,请求可能被禁止与证书无关。

希望“隐藏”当前存在的禁用的目标资源可能会以状态代码响应404(未找到)。

其他回答

其他答案缺少的是,必须理解RFC 2616上下文中的认证和授权仅指RFC 2617的HTTP认证协议。HTTP状态代码不支持RFC2617以外的方案进行认证,并且在决定是否使用401或403时不考虑。

Brief和Terse

未授权表示客户端未通过RFC2617认证,服务器正在启动认证过程。Forbidden表示客户端已通过RFC2617认证且没有授权,或者服务器不支持请求资源的RFC2617。

也就是说,如果您拥有自己的登录过程,并且从不使用HTTP身份验证,那么403始终是正确的响应,而401永远不应该使用。

详细和深入

来自RFC2616

10.4.2 401未授权请求需要用户身份验证。响应必须包括WWW Authenticate报头字段(第14.47节),该字段包含适用于所请求资源的质询。客户端可以使用适当的授权头字段重复请求(第14.8节)。

and

10.4.4 403禁止服务器理解该请求,但拒绝履行。授权不会有帮助,不应重复该请求。

首先要记住的是,本文档中的“身份验证”和“授权”特指RFC 2617中的HTTP身份验证协议。它们不引用您可能使用登录页面等创建的任何滚动您自己的身份验证协议。我将使用“登录”来引用除RFC2617以外的方法进行的身份验证和授权

因此,真正的区别不在于问题是什么,甚至不在于是否有解决方案。区别在于服务器希望客户端接下来做什么。

401指示无法提供资源,但服务器正在请求客户端通过HTTP身份验证登录,并已发送回复标头以启动进程。可能存在允许访问资源的授权,也可能没有,但让我们尝试一下,看看会发生什么。

403指示不能提供资源,并且对于当前用户来说,没有办法通过RFC2617来解决这一问题,也没有尝试的意义。这可能是因为已知没有足够的认证级别(例如,由于IP黑名单),但也可能是因为用户已经认证且没有权限。RFC2617模型是一个用户,一个证书,因此可以忽略用户可能具有可被授权的第二组证书的情况。它既不暗示也不暗示某种登录页面或其他非RFC2617认证协议可能有帮助,也可能没有帮助,这超出了RFC2616标准和定义。


编辑:RFC2616已过时,请参阅RFC7231和RFC7235。

他们未登录或不属于正确的用户组

你陈述了两种不同的情况;每种情况都应有不同的反应:

如果他们根本没有登录,您应该返回401未授权如果他们已登录但不属于正确的用户组,则应返回403禁止

根据收到的对此答案的评论,请注意RFC:

如果用户未登录,他们将被取消身份验证,其HTTP等效值为401,在RFC中被错误地称为“未授权”。如第10.4.2节所述,401未经授权:

“请求需要用户身份验证。”

如果您未经认证,401是正确的响应。然而,如果您未经授权,在语义正确的意义上,403是正确的响应。

丹尼尔·欧文(Daniel Irvine)的明确解释[原始链接]:

401 Unauthorized(401未授权)存在问题,这是身份验证错误的HTTP状态代码。这就是它:它用于身份验证,而不是授权。收到401响应时,服务器会告诉你,“你不是已验证–完全未验证或已验证不正确–但请重新验证并重试。”为了帮助您,它将始终包含一个WWW Authenticate标头,描述如何以进行身份验证。这是通常由web服务器而不是web返回的响应应用这也是非常暂时的;服务器要求您尝试再一次因此,为了获得授权,我使用403 Forbidden响应。它是永久性的,它与我的应用程序逻辑有关,而且更具体响应大于401。收到403响应时,服务器会告诉你:“对不起,我知道你是谁——我相信你说的你是谁,但你只是没有访问此资源的权限。也许如果你问系统管理员很好,你会得到许可的。但请不要打扰直到你的困境改变。”总之,401未经授权的响应应用于缺失或认证错误,应使用403禁止响应之后,当用户经过身份验证但未被授权对给定资源执行请求的操作。

另一种很好的图片格式,说明如何使用http状态代码。

  +-----------------------
  | RESOURCE EXISTS ? (if private it is often checked AFTER auth check)
  +-----------------------
    |       |
 NO |       v YES
    v      +-----------------------
   404     | IS LOGGED-IN ? (authenticated, aka user session)
   or      +-----------------------
   401        |              |
   403     NO |              | YES
   3xx        v              v
              401            +-----------------------
       (404 no reveal)       | CAN ACCESS RESOURCE ? (permission, authorized, ...)
              or             +-----------------------
             redirect          |            |
             to login       NO |            | YES
                               |            |
                               v            v
                               403          OK 200, redirect, ...
                      (or 404: no reveal)
                      (or 404: resource does not exist if private)
                      (or 3xx: redirection)

检查通常按以下顺序进行:

404如果资源是公共的且不存在或3xx重定向否则:401如果未登录或会话已过期403如果用户没有访问资源的权限(文件、json…)404如果资源不存在或不愿意透露任何信息,或3xx重定向

未授权:状态代码(401)指示请求需要身份验证,通常这意味着用户需要登录(会话)。服务器未知的用户/代理。可以使用其他凭据重复。注意:这令人困惑,因为它应该被命名为“未经验证”而不是“未经授权”。如果会话过期,登录后也可能发生这种情况。特殊情况:可以代替404使用,以避免显示资源的存在或不存在(credits@jiangCodeNinja)

禁止:状态代码(403),表示服务器理解请求但拒绝执行。服务器知道用户/代理,但没有足够的凭据。除非凭据更改,否则重复请求将不起作用,这在短时间内是非常不可能的。特殊情况:可以使用404代替404,以避免在显示资源的存在暴露敏感数据或向攻击者提供有用信息的情况下显示资源(credits@jiangCodeNinja)的存在或不存在。

未找到:状态代码(404),指示请求的资源不可用。用户/代理已知,但服务器不会透露任何有关资源的信息,就像它不存在一样。重复不起作用。这是404的一个特殊用法(例如github)。

如@ChrisH所述,有几个3xx重定向选项(301、302、303、307或根本不重定向,使用401):

HTTP重定向代码之间的差异浏览器缓存HTTP 301多长时间?重定向到登录页面时,正确的HTTP状态代码是什么?302和307重定向之间有什么区别?

这是一个更老的问题,但一个从未真正提出过的选项是返回404。从安全角度来看,投票最高的答案存在潜在的信息泄漏漏洞。例如,假设所讨论的安全网页是一个系统管理页面,或者更常见的是,是一个用户无权访问的系统记录。理想情况下,您不希望恶意用户知道那里有一个页面/记录,更不用说他们无权访问。当我构建这样的东西时,我将尝试在内部日志中记录未经验证/未经授权的请求,但返回404。

OWASP提供了有关攻击者如何将此类信息用作攻击一部分的更多信息。