Устранение ошибок HTTP 403 от шлюза API

Последнее обновление: 21 ноября 2022 г.

Когда я вызываю API шлюза Amazon API, я получаю сообщение об ошибке 403. Как устранить ошибки 403 от API Gateway?

Краткое описание

Код ответа HTTP 403 означает, что клиенту запрещен доступ к действительному URL-адресу. Сервер понимает запрос, но не может его выполнить из-за проблем на стороне клиента.

API шлюза API могут возвращать ответы 403 по любой из следующих причин:

Разрешение

Рассмотрим источник ошибки

Если сообщение об ошибке 403 поступило из других источников, возможно, причина ошибки другая. Например:

  • Если об ошибке сообщается в веб-браузере, то эта ошибка может быть вызвана неправильной настройкой прокси-сервера. Прокси-сервер возвращает ошибку 403, если HTTP-доступ запрещен.
  • Если перед API есть другой сервис AWS, то этот сервис может отклонить запрос с ошибкой 403 в ответе.
    Например: Amazon CloudFront.

Определите причину ошибки

Подтвердите, что запрошенный ресурс существует в определении API

Используйте curl для получения сведений о запросе и ответе

Если ошибка может быть воспроизведена, используйте команду curl -v , чтобы получить дополнительные сведения между клиентом и API, как показано ниже:

 curl -X HTTP_VERB -v https://{api_id}.execute-api.{region}.amazonaws.com/{stage_name}/{resource_name}

Примечание: Дополнительные сведения см. на веб-сайте проекта curl.

Если ошибка является результатом недействительного ключа API, убедитесь, что в запросе был отправлен заголовок «x-api-key» .

Убедитесь, что настройки DNS на любом интерфейсе конечных точек Amazon VPC установлены правильно

Примечание. Подтвердите следующее для API, вызываемых из Amazon VPC, который имеет только конечную точку интерфейса VPC.

Убедитесь, что параметр DNS конечной точки интерфейса задан правильно в зависимости от типа используемого вами API.

Имейте в виду следующее:

  • Чтобы вызвать региональный API из Amazon VPC, частные DNS-имена должны быть деактивированы на конечной точке интерфейса. Затем имя хоста конечной точки может быть разрешено общедоступным DNS. Дополнительные сведения см. в разделе Создание частного API в Amazon API Gateway.
  • Чтобы вызвать частный API из Amazon VPC с использованием частного DNS-имени API, необходимо активировать частные DNS-имена на конечной точке интерфейса. Затем имя хоста конечной точки интерфейса можно преобразовать в ресурсы локальной подсети Amazon VPC. Дополнительные сведения см. в разделе Как вызвать частный API.
    Примечание. Вам не нужно настраивать частный DNS, если вы вызываете частный API с помощью одного из следующих способов:
    Общедоступное DNS-имя частного API.
    -или-
    Псевдоним Amazon Route 53.

Просмотрите политику ресурсов API

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

  • (для API, вызываемых из Amazon VPC с конечной точкой интерфейса VPC) Политика ресурсов API предоставляет Amazon VPC или конечной точке интерфейса доступ к API.
  • Спецификации ресурсов и форматирование политики ресурсов верны.
    Примечание: При сохранении политики ресурсов проверка спецификации ресурса не выполняется. Примеры см. в разделе Примеры политики ресурсов шлюза API.
  • Вызывающему абоненту разрешено вызывать конечную точку API в соответствии с типом проверки подлинности, который вы определили для API. Дополнительные сведения см. в разделе Как политики ресурсов шлюза API влияют на рабочий процесс авторизации.

Просмотр HTTP-запросов и ответных сообщений

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

Примечание: Для автономного анализа сохраните сообщения в файле HTTP-архива (HAR).

Помогла ли эта статья?

Отправить отзыв

Вам нужна техническая поддержка или выставление счетов?

Обратитесь в службу поддержки AWS

Войдите в консоль

Узнайте об AWS

  • Что такое AWS?
  • Что такое облачные вычисления?
  • AWS Разнообразие, равенство и инклюзивность
  • Что такое DevOps?
  • Что такое контейнер?
  • Что такое озеро данных?
  • Облачная безопасность AWS
  • Что нового
  • Блоги
  • Пресс-релизы

Ресурсы для AWS

  • Начало работы
  • Обучение и сертификация
  • Библиотека решений AWS
  • Архитектурный центр
  • Часто задаваемые вопросы по продуктам и техническим вопросам
  • Аналитические отчеты
  • Партнеры AWS

Разработчики на AWS

  • Центр разработчиков
  • SDK и инструменты
  • . NET на AWS
  • Python на AWS
  • Java на AWS
  • PHP на AWS
  • JavaScript на AWS

Помощь

  • Свяжитесь с нами
  • Подайте заявку в службу поддержки
  • Центр знаний
  • AWS re: Сообщение
  • Обзор поддержки AWS
  • Юридический
  • Карьера в AWS

Amazon является работодателем с равными возможностями: Меньшинства / Женщины / Инвалидность / Ветеран / Гендерная идентичность / Сексуальная ориентация / Возраст.

  • Конфиденциальность
  • |
  • Условия сайта
  • |
  • Настройки файлов cookie
  • |
  • © 2023, Amazon Web Services, Inc. или ее дочерние компании. Все права защищены.

Поддержка AWS для Internet Explorer заканчивается 31. 07.2022. Поддерживаемые браузеры: Chrome, Firefox, Edge и Safari. Узнать больше »

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

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

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

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

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

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

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

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

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

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

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

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

Твитнуть это

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

Начнем с простого случая: клиент вызывает ваш защищенный 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Код состояния 0214 403 не дает реальной полезной информации. Вы можете подумать, что в этом случае имеет смысл возвращать код состояния 401 . Ведь ресурс принадлежит другому пользователю, поэтому и запрос должен исходить от другого пользователя.

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

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

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

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

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

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

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

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

Резюме

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

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

    No related posts.