Вопрос: 403 Запрещено vs 401 Неавторизованные ответы HTTP


Для веб-страницы, которая существует, но для которой пользователь, который не имеет достаточных привилегий (они не вошли в систему или не принадлежат к соответствующей группе пользователей), каков надлежащий ответ HTTP для обслуживания? 401? 403? Что-то другое? То, что я читал на каждом из них до сих пор, не очень ясно видно о различии между ними. Какие варианты использования подходят для каждого ответа?


1847


источник


Ответы:


Четкое объяснение Даниэль Ирвин :

Проблема с 401 Несанкционированный , код состояния HTTP для ошибок аутентификации. И это все: это для аутентификации, а не авторизации.   Получение ответа 401 - это сервер, который говорит вам: «вы не   аутентифицированный - либо не аутентифицированный вообще, либо аутентифицированный   неверно, но повторите проверку и повторите попытку ». Чтобы помочь вам,   он всегда будет включать WWW-Authenticate заголовок, который описывает, как   для аутентификации.

Это ответ, который обычно возвращается вашим веб-сервером, а не веб-сайтом   заявление.

Это тоже что-то очень временное; сервер просит вас попробовать   еще раз.

Поэтому для авторизации я использую 403 Запрещено ответ. Это   постоянный, он привязан к моей логике приложения, и это более конкретный   чем 401.

Получение ответа 403 - это сервер, который говорит вам: «Извините. я знаю   кто вы есть, я верю, кто вы так говорите, но у вас просто нет   разрешение на доступ к этому ресурсу. Возможно, если вы спросите систему   администратор, вы получите разрешение. Но, пожалуйста, не беспокойтесь   я снова, пока ваше затруднительное положение не изменится ».

Таким образом, 401 Несанкционированный ответ следует использовать для   или плохой аутентификации, и 403 Запрещено следует использовать ответ   впоследствии, когда пользователь аутентифицирован, но не имеет права на   выполнить запрошенную операцию на данном ресурсе.

Другая красивый живописный формат о том, как использовать коды статуса http.


2752



Видеть RFC2616 :

401 Несанкционированный:

Если запрос уже включил учетные данные авторизации, то ответ 401 указывает, что для этих учетных данных было отказано в авторизации.

403 Запрещено:

Сервер понял запрос, но отказывается его выполнять.

Обновить

Из вашего варианта использования кажется, что пользователь не аутентифицирован. Я вернусь 401.


Редактировать: RFC2616 устарел, см. RFC7231 а также RFC7235 ,


332



Что-то, чего не хватает другим, заключается в том, что следует понимать, что аутентификация и авторизация в контексте RFC 2616 относится ТОЛЬКО к протоколу HTTP аутентификации RFC 2617. Аутентификация по схемам вне RFC2617 не поддерживается в кодах состояния HTTP и не рассматривается при принятии решения о том, следует ли использовать 401 или 403.

Краткая и краткая

Unauthorized указывает, что клиент не аутентифицирован RFC2617, и сервер инициирует процесс аутентификации. Запрет указывает либо на то, что клиент RFC2617 аутентифицирован и не имеет авторизации, либо что сервер не поддерживает RFC2617 для запрошенного ресурса.

Если у вас есть собственный процесс входа в систему и никогда не используется HTTP-аутентификация, 403 всегда будет правильным ответом, и 401 никогда не будет использоваться.

Подробное и всестороннее

Из RFC2616

10.4.2 401 Несанкционированный

Запрос требует аутентификации пользователя. Ответ ДОЛЖЕН включать поле заголовка WWW-Authenticate (раздел 14.47), содержащее вызов, применимый к запрашиваемому ресурсу. Клиент МОЖЕТ повторить запрос с подходящим полем заголовка авторизации (раздел 14.8).

а также

10.4.4 403 Запрещено   Сервер понял запрос, но отказывается его выполнять. Авторизация не поможет, и запрос НЕ ДОЛЖЕН повториться.

Прежде всего следует иметь в виду, что «Аутентификация» и «Авторизация» в контексте этого документа относятся конкретно к протоколам HTTP-аутентификации из RFC 2617. Они не ссылаются на какие-либо собственные протоколы аутентификации, которые вы могли бы создать используя страницы входа и т. д. Я буду использовать «login», чтобы ссылаться на аутентификацию и авторизацию с помощью методов, отличных от RFC2617

Таким образом, реальная разница не в том, что проблема, или даже при наличии решения. Разница в том, что сервер ожидает от клиента следующего.

401 указывает, что ресурс не может быть предоставлен, но сервер ЗАПРОСИТ, что клиент входит в систему через HTTP-аутентификацию и отправил заголовки ответов, чтобы инициировать процесс. Возможно, есть разрешения, которые разрешают доступ к ресурсу, возможно, нет, но давайте попробуем и посмотрим, что произойдет.

403 указывает, что ресурс не может быть предоставлен, и для текущего пользователя нет способа решить эту проблему с помощью RFC2617 и нет смысла пытаться. Это может быть связано с тем, что известно, что уровень аутентификации не достаточен (например, из-за черного списка IP), но это может быть связано с тем, что пользователь уже прошел аутентификацию и не имеет полномочий. Модель RFC2617 является однопользовательской, односерверной, поэтому случай, когда пользователь может иметь второй набор учетных данных, которые могут быть разрешены, может быть проигнорирован. Это не предполагает и не подразумевает, что какая-то страница входа или другой протокол проверки подлинности, не относящийся к RFC2617, может или не может помочь - это вне стандартов и определения RFC2616.


Редактировать: RFC2616 устарел, см. RFC7231 а также RFC7235 ,


247



В соответствии с RFC 2616 (HTTP / 1.1) 403 отправляется, когда:

Сервер понял запрос, но отказывается его выполнять. Авторизация не поможет, и запрос НЕ ДОЛЖЕН повториться. Если метод запроса не был HEAD, и сервер хочет сообщить, почему запрос не был выполнен, ему ДОЛЖЕН описать причину отказа в сущности. Если сервер не желает предоставлять эту информацию клиенту, вместо этого может использоваться код состояния 404 (Not Found)

Другими словами, если клиент МОЖЕТ получить доступ к ресурсу путем аутентификации, следует отправить 401.


93



Версия TL; DR

Ресурс GET существует?
    | |
    | |
    v v
НЕТ: 404 ДА: аутентифицировано?
             | |
             | |
             v v
           НЕТ: 401 ДА: Может ли доступ к ресурсу?
           (или: 404) | |
           или 301 | |
           перенаправить v v
           для входа в систему NO: 403 OK 200, 301, ... 

Проверки обычно выполняются в следующем порядке:

  • 401, если не завершен вход или сеанс
  • 403, если у пользователя нет разрешения на доступ к ресурсу
  • 404, если ресурс не существует

НЕСАНКЦИОНИРОВАННОЕ : Код состояния (401), указывающий, что запрос требует аутентификация , Пользователь / агент неизвестен сервером. Может повторяться с другими учетными данными. ПРИМЕЧАНИЕ. Это запутывает, поскольку это должно было быть названо «unauthenticated» вместо «unauthorized».

ЗАПРЕЩЕНО : Код состояния (403), указывающий, что сервер понял запрос, но отказался выполнить его. Пользователь / агент, известный сервером, но имеющий недостаточные полномочия , Повторный запрос не будет работать.

НЕ НАЙДЕНО : Код состояния (404), указывающий, что запрошенный ресурс недоступен. Известный пользователь / агент, но сервер ничего не сообщает об этом ресурсе, как будто его не существует. Повторение не будет работать. Это специальное использование 404 (например, github).


42



Если аутентификация в качестве другого пользователя предоставит доступ к запрашиваемому ресурсу, тогда необходимо вернуть 401 Unauthorized. 403 Запрещено в основном использовать, когда доступ к ресурсу запрещен всем или ограничен определенной сетью или разрешен только через SSL, независимо от того, что он не связан с аутентификацией.

Из RFC 7235 (протокол передачи гипертекста (HTTP / 1.1): аутентификация):

3.1. 401 Несанкционированный

Код состояния 401 (Несанкционированный) указывает, что запрос имеет   не применяется, поскольку в нем отсутствуют достоверные аутентификационные данные   для целевого ресурса. Исходный сервер ДОЛЖЕН отправить   Поле заголовка WWW-Authenticate (раздел 4.4), содержащее хотя бы один   вызов, применимый к целевому ресурсу. Если запрос   включены учетные данные аутентификации, затем ответ 401   указывает, что разрешение было отклонено для тех   полномочия , Клиент МОЖЕТ повторить запрос с помощью нового или   замените поле заголовка полномочий (раздел 4.1). Если 401   ответ содержит ту же задачу, что и предыдущий ответ, и   пользовательский агент уже попытался выполнить аутентификацию хотя бы один раз, затем   пользовательский агент ДОЛЖЕН представить прилагаемое представление к   пользователь, поскольку он обычно содержит соответствующую диагностическую информацию.

И это из RFC 2616:

10.4.4 403 Запрещено

Сервер понял запрос, но отказывается его выполнять.
Авторизация не поможет и запрос НЕ ДОЛЖЕН повториться.
Если метод запроса не был HEAD, и сервер хочет сделать
что запрос не был выполнен, ему ДОЛЖНО описать   причина отказа в юридическом лице. Если сервер не желает   сделать эту информацию доступной для клиента, код состояния 404
(Не найдено).

Изменить: RFC 7231 (протокол передачи гипертекста (HTTP / 1.1): семантика и контент) изменяет значение 403:

6.5.3. 403 Запрещено

Код статуса 403 (Forbidden) указывает, что сервер   понимал просьбу, но отказывался ее санкционировать. Сервер, который   желает обнародовать, почему запрос был запрещен, может   описать эту причину в полезной нагрузке ответа (если таковая имеется).

Если в запросе были предоставлены учетные данные,
сервер считает их недостаточными для предоставления доступа. Клиент
НЕ ДОЛЖНО автоматически повторять запрос с тем же
полномочия. Клиент МОЖЕТ повторить запрос с новым или другим   полномочия. Однако запрос может быть запрещен по причинам
не связанных с полномочиями.

Сервер происхождения, который хочет «скрыть» текущее существование
запрещенный целевой ресурс МОЖЕТ вместо этого отвечать кодом состояния
404 Не Найдено).

Таким образом, 403 теперь может означать что угодно. Предоставление новых учетных данных может помочь ... или, возможно, нет.


35



Это более старый вопрос, но один из вариантов, который никогда не был поднят, состоял в том, чтобы вернуть 404. С точки зрения безопасности, самый высокий голосовой ответ страдает от потенциального уязвимость утечки информации , Скажем, например, что рассматриваемая защищенная веб-страница является системной административной страницей или, что чаще всего, является записью в системе, к которой у пользователя нет доступа. В идеале вы не хотите, чтобы злонамеренный пользователь даже знал, что там есть страница / запись, не говоря уже о том, что у них нет доступа. Когда я создаю что-то вроде этого, я попытаюсь записать неавторизованные / неавторизованные запросы во внутреннем журнале, но верну 404.

OWASP имеет некоторые больше информации о том, как злоумышленник может использовать этот тип информации как часть атаки.


20



This question was asked some time ago, but people's thinking moves on.

Section 6.5.3 in this draft (authored by Fielding and Reschke) gives status code 403 a slightly different meaning to the one documented in RFC 2616.

It reflects what happens in authentication & authorization schemes employed by a number of popular web-servers and frameworks.

I've emphasized the bit I think is most salient.

6.5.3. 403 Forbidden

The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).

If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.

An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).

Whatever convention you use, the important thing is to provide uniformity across your site / API.


19



Practical Examples

If apache requires authentication (via .htaccess), and you hit Cancel, it will respond with a 401 Authorization Required

If nginx finds a file, but has no access rights (user/group) to read/access it, it will respond with 403 Forbidden

RFC (2616 Section 10)

401 Unauthorized (10.4.2)

Meaning 1: Need to authenticate

The request requires user authentication. ...

Meaning 2: Authentication insufficient

... If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. ...

403 Forbidden (10.4.4)

Meaning: Unrelated to authentication

... Authorization will not help ...

More details:

  • The server understood the request, but is refusing to fulfill it.

  • It SHOULD describe the reason for the refusal in the entity

  • The status code 404 (Not Found) can be used instead

    (If the server wants to keep this information from client)

TL;DR

  • 401: Every refusal that has to do with authentication
  • 403: Every refusal that has NOTHING to do with authentication

8