HTTP предоставляет общий механизм управления доступом и аутентификации. Эта страница знакомит с механизмом аутентификации HTTP и показывает, как ограничить доступ к серверу с помощью схемы HTTP «Basic».

Общий механизм аутентификации HTTP

RFC 7235 определяет механизм аутентификации HTTP, который сервер может использовать, чтобы запросить аутентификацию клиента, а клиент — чтобы предоставить данные аутентификации.

Обмен запросом аутентификации и ответом работает следующим образом:

1. Сервер отвечает клиенту статусом 401 (Не авторизован) и сообщает, как пройти аутентификацию, с помощью заголовка ответа WWW-Authenticate, содержащего как минимум один запрос аутентификации.
2. Клиент, желающий пройти аутентификацию на сервере, может сделать это, включив в запрос заголовок Authorization с учетными данными.
3. Обычно клиент показывает пользователю запрос на ввод пароля, а затем отправляет запрос с правильным заголовком Authorization.

Описанный выше общий обмен сообщениями одинаков для большинства (если не для всех) схем аутентификации. Фактическое содержимое заголовков и способ его кодирования различаются!

Аутентификация через прокси-сервер

Тот же механизм запроса аутентификации и ответа можно использовать для аутентификации через прокси-сервер. Поскольку аутентификация ресурса и аутентификация через прокси-сервер могут сосуществовать, для них нужны разные заголовки и коды состояния. В случае прокси-серверов используется код состояния 407 (Требуется аутентификация на прокси-сервере), заголовок ответа Proxy-Authenticate содержит как минимум один запрос аутентификации, применимый к прокси-серверу, а заголовок запроса Proxy-Authorization используется для передачи учетных данных прокси-серверу.

Доступ запрещен

Если (прокси-)сервер получает недействительные учетные данные, он должен ответить кодом состояния 401 Unauthorized или 407 Proxy Authentication Required, после чего пользователь может отправить новый запрос или заменить поле заголовка Authorization.

Если (прокси-)сервер получает действительные учетные данные, которых недостаточно для доступа к ресурсу, он должен ответить кодом состояния 403 Forbidden. В отличие от 401 Unauthorized или 407 Proxy Authentication Required, в этом случае пользователь не может пройти аутентификацию, и браузеры не предложат повторить попытку.

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

Аутентификация изображений из источников другого происхождения

Потенциальная уязвимость (с тех пор устраненная в браузерах) заключалась в аутентификации изображений с других сайтов. Начиная с Firefox 59, ресурсы изображений, загружаемые из источников, отличных от источника текущего документа, больше не могут вызывать диалоговые окна аутентификации HTTP (ошибка Firefox 1423146). Это предотвращает кражу учетных данных пользователей в случаях, когда злоумышленникам удается встроить произвольное изображение на стороннюю страницу.

Кодировка символов при аутентификации HTTP

Браузеры используют кодировку utf-8 для имен пользователей и паролей.

Раньше Firefox использовал ISO-8859-1, но перешел на utf-8, чтобы соответствовать другим браузерам и избежать потенциальных проблем, описанных в ошибке Firefox 1419658.

Заголовки WWW-Authenticate и Proxy-Authenticate

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

Синтаксис этих заголовков выглядит следующим образом:

WWW-Authenticate: <type> realm=<realm>
Proxy-Authenticate: <type> realm=<realm>

Здесь <type> — это схема аутентификации (наиболее распространена схема «Basic», описанная ниже). Область используется для описания защищенной области или указания границ защиты. Это может быть, например, сообщение «Доступ к тестовому сайту», чтобы пользователь знал, к какой области пытается получить доступ.

Заголовки Authorization и Proxy-Authorization

Заголовки запросов Authorization и Proxy-Authorization содержат учетные данные для аутентификации пользовательского агента на (прокси-)сервере. Здесь снова требуется <type>, за которым следуют учетные данные. В зависимости от используемой схемы аутентификации они могут быть закодированы или зашифрованы.

Authorization: <type> <credentials>
Proxy-Authorization: <type> <credentials>

Схемы аутентификации

Общий механизм аутентификации HTTP служит основой для ряда схем аутентификации.

IANA ведет список схем аутентификации, однако существуют и другие схемы, предлагаемые хостинговыми сервисами, например Amazon AWS.

К распространенным схемам аутентификации относятся:

Basic

См. RFC 7617: учетные данные, закодированные в base64. Подробнее — ниже.

Bearer

См. RFC 6750: токены Bearer для доступа к ресурсам, защищенным OAuth 2.0

Digest

См. RFC 7616. Firefox 93 и более поздние версии поддерживают алгоритм SHA-256. Предыдущие версии поддерживают только хеширование MD5 (не рекомендуется).

HOBA

См. RFC 7486, раздел 3: HTTP Origin-Bound Authentication — аутентификация на основе цифровой подписи, привязанная к источнику HTTP

Mutual

См. RFC 8120

Negotiate / NTLM

См. RFC4599

VAPID

См. RFC 8292

SCRAM

См. RFC 7804

AWS4-HMAC-SHA256

См. документацию AWS. Эта схема используется для аутентификации серверов AWS3.

Схемы могут различаться уровнем безопасности и доступностью в клиентском и серверном программном обеспечении.

Схема аутентификации «Basic» обеспечивает очень низкий уровень безопасности, но широко поддерживается и проста в настройке. Ниже она описана подробнее.

Схема аутентификации Basic

Схема HTTP-аутентификации «Basic» определена в RFC 7617. Она передает учетные данные в виде пар «идентификатор пользователя/пароль», закодированных с помощью base64.

Безопасность базовой аутентификации

Поскольку идентификатор пользователя и пароль передаются по сети в открытом виде (они закодированы в base64, но кодировка base64 обратима), схема базовой аутентификации небезопасна. Чтобы предотвратить перехват учетных данных, при базовой аутентификации следует использовать HTTPS/TLS.

Кроме того, сайты, использующие HTTP Basic Auth, особенно уязвимы для атак межсайтовой подделки запроса (CSRF), поскольку учетные данные пользователя отправляются во всех запросах независимо от их источника (в отличие от механизмов аутентификации на основе файлов cookie, поскольку файлы cookie обычно блокируются в межсайтовых запросах). При изменении данных сайтам всегда следует использовать запросы POST и включать токены CSRF.

Без этих мер безопасности базовую аутентификацию не следует использовать для защиты конфиденциальной или ценной информации.

Ограничение доступа с помощью Apache и базовой аутентификации

Чтобы защитить каталог паролем на сервере Apache, вам понадобятся файл .htaccess и файл .htpasswd.

Файл .htaccess обычно выглядит так:

AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user

В файле .htaccess указывается файл .htpasswd, в каждой строке которого записаны имя пользователя и пароль, разделенные двоеточием (:). Фактические пароли просмотреть нельзя, поскольку они хешированы (в данном случае с помощью хеширования на основе MD5). Обратите внимание: файл .htpasswd можно назвать по-другому, но помните, что он не должен быть доступен посторонним. (Обычно Apache настроен так, чтобы предотвращать доступ к файлам .ht*).

aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/

Ограничение доступа с помощью Nginx и базовой аутентификации

Для Nginx необходимо указать местоположение, которое требуется защитить, и директиву auth_basic, задающую имя области, защищенной паролем. Затем директива auth_basic_user_file указывает на файл .htpasswd с зашифрованными учетными данными пользователей, как и в приведенном выше примере с Apache.

location /status {
    auth_basic           "Access to the staging site";
    auth_basic_user_file /etc/apache2/.htpasswd;
}

Доступ с помощью учетных данных в URL

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

https://username:password@www.example.com/

В современных браузерах такой синтаксис больше не разрешен: имя пользователя и пароль удаляются из запроса до его отправки.

См. также

• WWW-Authenticate
• Authorization
• Proxy-Authorization
• Proxy-Authenticate
• 401, 403, 407
• Рекомендации по обеспечению безопасности HTTP