Запрещено (403), Несанкционировано (401) или что еще?

Предположим, ваш веб-API защищен, и клиент пытается получить к нему доступ без соответствующих учетных данных. Как вы справляетесь с этим сценарием? Скорее всего, вы знаете, что должны вернуть код состояния HTTP. Но какой из них более подходящий? Должен ли это быть 401 Неавторизованный или 403 Запрещенный ? Или, может быть, что-то еще?

Как обычно, зависит 🙂. Это зависит от конкретного сценария, а также от уровня безопасности, который вы хотите обеспечить. Давайте немного углубимся.

Если хотите, можете посмотреть видео на ту же тему:

Прежде чем углубляться в конкретную тему, давайте кратко рассмотрим смысл кодов состояния HTTP в целом. Большинство веб-API вдохновлены парадигмой REST. Хотя подавляющее большинство из них на самом деле не реализуют REST, они обычно следуют нескольким соглашениям RESTful, когда речь идет о кодах состояния HTTP.

Основной принцип, лежащий в основе этих соглашений, заключается в том, что код состояния, возвращаемый в ответе, должен информировать клиента о том, что происходит и что сервер ожидает от клиента в следующий раз . Вы можете выполнить этот принцип, ответив на следующие вопросы:

• Есть проблема или нет?
• Если есть проблема, на какой стороне она? На стороне клиента или на стороне сервера?
• Что делать клиенту в случае возникновения проблемы?

Это общий принцип, применимый ко всем кодам состояния HTTP. Например, если клиент получает код состояния 200 OK , он знает, что с его запросом не было проблем, и ожидает запрошенное представление ресурса в теле ответа. Если клиент получает 201 Создан код состояния , он знает, что с его запросом не было проблем, но представление ресурса отсутствует в теле ответа. Точно так же, когда клиент получает код состояния 500 Internal Server Error , он знает, что это проблема на стороне сервера, и клиент не может ничего сделать, чтобы смягчить ее.

Таким образом, ответ вашего веб-API должен предоставить клиенту достаточно информации, чтобы понять, как он может двигаться вперед в нужное время.

Рассмотрим случай, когда клиент пытается вызвать защищенный API. Если клиент предоставляет соответствующие учетные данные (например, действительный токен доступа), его запрос принимается и обрабатывается. Что происходит, когда у клиента нет соответствующих учетных данных? Какой код состояния должен возвращать ваш API, если запрос является незаконным? Какую информацию он должен возвращать и как гарантировать наилучшую безопасность?

К счастью, в контексте безопасности OAuth у вас есть некоторые рекомендации. Конечно, вы можете использовать их, даже если вы не используете OAuth для защиты своего API.

«Основной принцип кодов состояния REST заключается в том, что код состояния должен информировать клиента о том, что происходит и что сервер ожидает от клиента в следующий раз»

Tweet This

Когда использовать 400 Запрос?

Начнем с простого случая: клиент вызывает ваш защищенный API, опуская обязательный параметр. В этом случае ваш API должен ответить 400 Код состояния Bad Request . На самом деле, если этот параметр требуется, ваш API не может даже обработать запрос клиента. Запрос клиента имеет неверный формат.

Ваш API должен возвращать один и тот же код состояния, даже если клиент предоставляет неподдерживаемый параметр или повторяет один и тот же параметр несколько раз в своем запросе. В обоих случаях запрос клиента не соответствует ожиданиям и должен быть отклонен .

Следуя общему принципу, описанному выше, клиент должен иметь возможность понять, что делать, чтобы решить проблему. Итак, вы должны добавить в тело своего ответа, что не так с запросом клиента. Вы можете предоставить эти сведения в предпочитаемом вами формате, таком как простой текст, XML, JSON и т. д. Однако использование стандартного формата, подобного тому, который предлагается в спецификациях API-интерфейсов HTTP «Сведения о проблеме», будет более подходящим для обеспечения единообразного управления проблемами во всех клиенты.

Например, если ваш клиент вызывает ваш API с пустым значением для обязательного параметра data , API может ответить следующим ответом:

 HTTP/1.1 400 Bad Request
Content-Type: приложение/проблема+json
Язык содержания: en
{
  "тип": "https://myapi.com/validation-error",
  "title": "Ошибка проверки",
  "detail": "Параметры вашего запроса недействительны.",
  "неверные параметры": [
    {
      "имя": "данные",
      "причина": "не может быть пустым."
    }
  ]
} 

Когда использовать 401 Неавторизованный?

Теперь предположим, что клиент вызывает ваш защищенный API с правильно сформированным запросом, но без действительных учетных данных. Например, в контексте OAuth это может произойти в одном из следующих случаев:

• Отсутствует токен доступа.
• Токен доступа просрочен, отозван, имеет неправильный формат или недействителен по другим причинам.

В обоих случаях соответствующий код состояния для ответа — 401 Неавторизованный . В духе взаимного сотрудничества между клиентом и API ответ должен содержать подсказку о том, как получить такую ​​авторизацию. Это приходит в форме Заголовок WWW-Authenticate с конкретной используемой схемой аутентификации. Например, в случае OAuth3 ответ должен выглядеть следующим образом:

 HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example" 

Вы должны использовать схему Bearer и предоставить параметр realm , чтобы указать набор ресурсов, которые защищает API.

Если запрос клиента не содержит токена доступа, демонстрирующего, что он не знал о защите API, ответ API не должен содержать никакой другой информации.

С другой стороны, если запрос клиента включает токен доступа с истекшим сроком действия, ответ API может включать причину отказа в доступе, как показано в следующем примере:

 HTTP/1.1 401 Несанкционировано
WWW-аутентификация: Bearer realm="example",
                  ошибка = "недействительный_токен",
                  error_description="Срок действия маркера доступа истек" 

Когда использовать 403 Запрещено?

Теперь давайте рассмотрим другой случай. Предположим, например, что ваш клиент отправляет запрос на изменение документа и предоставляет действительный токен доступа к API. Однако этот токен не включает и не подразумевает каких-либо разрешений или областей действия, которые позволяют клиенту выполнять желаемое действие.

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

Чтобы помочь клиенту понять, что делать дальше, ваш API может указать в своем ответе, какие привилегии необходимы. Например, согласно рекомендациям OAuth3, ваш API может включать информацию об отсутствующей области для доступа к защищенному ресурсу.

Попробуйте самую мощную платформу аутентификации бесплатно. Начало работы →

Вопросы безопасности

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

Что делать с деталями ответа

Основной задачей безопасности является недопущение предоставления полезной информации потенциальным злоумышленникам . Другими словами, возврат подробной информации в ответах API на попытки доступа к защищенным ресурсам может представлять угрозу безопасности.

Например, предположим, что ваш API возвращает код состояния 401 Unauthorized с описанием ошибки, например Срок действия токена доступа истек . В этом случае он дает информацию о самом токене потенциальному злоумышленнику. То же самое происходит, когда ваш API отвечает кодом состояния 403 Forbidden и сообщает об отсутствующей области или привилегии.

Другими словами, обмен этой информацией может улучшить взаимодействие между клиентом и сервером в соответствии с основным принципом парадигмы REST. Однако та же информация может быть использована злоумышленниками для разработки своей стратегии атаки .

Поскольку эта дополнительная информация является необязательной как для спецификаций HTTP, так и для рекомендаций по токену-носителю OAuth3, возможно, вам следует тщательно подумать о ее совместном использовании. Основной принцип предоставления дополнительной информации должен основываться на ответе на этот вопрос: как клиент будет вести себя иначе, если ему будет предоставлена ​​дополнительная информация?

Например, в случае ответа с 401 Неавторизованный код состояния . Изменяется ли поведение клиента, когда он узнает, что его токен просрочен или отозван? В любом случае он должен запросить новый токен. Таким образом, добавление этой информации не меняет поведение клиента.

Иначе обстоит дело с 403 Запрещено . Сообщая вашему клиенту, что ему требуется определенное разрешение, ваш API заставляет его узнать, что делать дальше, то есть запрашивать это дополнительное разрешение. Если ваш API не предоставляет эту дополнительную информацию, он будет ведет себя иначе, чем , потому что не знает, что делать, чтобы получить доступ к этому ресурсу.

Не сообщайте клиенту…

Теперь предположим, что ваш клиент пытается получить доступ к ресурсу, к которому он вообще НЕ ДОЛЖЕН обращаться, например, потому что он принадлежит другому пользователю. Какой код состояния должен возвращать ваш API? Должен ли он возвращать код состояния 403 или 401 ?

В любом случае у вас может возникнуть соблазн вернуть код состояния 403 . Но на самом деле вы не можете предложить отсутствующее разрешение, потому что у этого клиента нет доступа к этому ресурсу. Итак, 9Код состояния 0003 403 не дает реальной полезной информации. Вы можете подумать, что в этом случае имеет смысл возвращать код состояния 401 . Ведь ресурс принадлежит другому пользователю, поэтому и запрос должен исходить от другого пользователя.

Однако, поскольку этот ресурс не должен быть доступен текущему клиенту, лучше всего скрыть его. Предоставление клиенту (и особенно пользователю, стоящему за ним) информации о том, что ресурс существует, может привести к небезопасным прямым ссылкам на объекты (IDOR), уязвимости управления доступом, основанной на знании ресурсов, к которым у вас нет доступа. Поэтому в этих случаях ваш API должен отвечать 404 Not Found код состояния. Это опция, предусмотренная спецификацией HTTP:

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

Например, это стратегия, принятая GitHub, когда у вас нет разрешения на доступ к репозиторию. Этот подход позволяет избежать повторной попытки злоумышленника получить доступ к ресурсу с несколько иной стратегией.

Что делать с неправильными запросами

Когда клиент отправляет некорректный запрос, вы должны ответить с кодом состояния 400 Bad Request . У вас может возникнуть соблазн проанализировать правильность запроса перед оценкой учетных данных клиента. Вы не должны этого делать по нескольким причинам:

• Оценивая учетные данные клиента перед действительностью запроса, вы избегаете обработки запросов API, которые не могут быть там.
• Потенциальный злоумышленник может выяснить, как должен выглядеть запрос без аутентификации, даже до получения или кражи законного токена доступа.

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

Обсуждаемые здесь меры безопасности должны применяться в производственной среде. Конечно, в среде разработки ваш API может предоставить всю информацию, необходимую для диагностики причин сбоя авторизации.

Резюме

Из этой статьи вы узнали, что:

• 400 Неверный запрос — это код состояния, который возвращается, когда форма запроса клиента не соответствует ожиданиям API.
• 401 Неавторизованный — это код состояния, который возвращается, когда клиент не предоставляет учетные данные или неверные учетные данные.
• 403 Запрещено — это код состояния, который возвращается, когда у клиента есть действительные учетные данные, но недостаточно привилегий для выполнения действия над ресурсом.

Вы также узнали, что некоторые проблемы с безопасностью могут возникнуть, когда ваш API раскрывает детали, которыми могут воспользоваться злоумышленники. В этих случаях вы можете использовать более ограниченную стратегию, включив в тело ответа только необходимые данные или даже используя код состояния 404 Not Found вместо 403 Forbidden или 401 Unauthorized .

Следующая шпаргалка обобщает то, что вы узнали:

Ошибка HTTP 403.16 при доступе к веб-сайту — информационные службы Интернета

Редактировать

Твиттер LinkedIn Фейсбук Эл. адрес

• Статья
• 25.01.2022
• 2 минуты на чтение

Эта статья поможет вам устранить ошибку HTTP 403.16 — Forbidden , возникающую при доступе к веб-сайту, размещенному в Internet Information Services (IIS) 7.0.

Исходная версия продукта:   Информационные службы Интернета 7.0
Исходный номер базы знаний:   942061

Симптомы

У вас есть веб-сайт, размещенный на IIS 7. 0. При попытке доступа к сайту через веб-браузер появляется сообщение об ошибке, похожее на один из следующих примеров.

Причина 1. Корневой сертификат отсутствует в хранилище сертификатов доверенных корневых центров сертификации

Эта проблема возникает из-за того, что корневой сертификат центра сертификации отсутствует в хранилище сертификатов доверенных корневых центров сертификации на веб-сервере IIS.

Примечание

Корневой сертификат центра сертификации используется для выдачи сертификата клиента.

В хранилище сертификатов доверенных корневых центров сертификации имеется один или несколько несамоподписанных сертификатов. Несамоподписанный сертификат — это любой сертификат, для которого значения , выданные , и , выданные , не совпадают в точности.

Решение по причине 1

1. На веб-сервере IIS выберите Пуск , введите mmc.exe в поле Начать поиск , щелкните правой кнопкой мыши mmc. exe и выберите Запуск от имени администратора .

   Примечание

   При появлении запроса на ввод пароля администратора или подтверждения введите пароль или выберите Продолжить .

2. В меню File выберите Add/Remove Snap-in .

3. Под Доступные оснастки , выберите Сертификаты , а затем выберите Добавить .

4. Выберите Учетная запись компьютера , а затем выберите Далее .

5. Выберите Локальный компьютер , выберите Готово , а затем выберите Закрыть .

6. Чтобы выйти из мастера, выберите OK .

7. Разверните Сертификаты , разверните Доверенные корневые центры сертификации , щелкните правой кнопкой мыши Сертификаты , выберите Все задачи , а затем выберите Импорт .