Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
HTTP
Способы запроса
Поля заголовка
Коды состояния
Методы управления безопасным доступом
Уязвимости безопасности

В контексте транзакции HTTP базовая аутентификация доступа - это метод, с помощью которого пользовательский агент HTTP (например, веб-браузер ) предоставляет имя пользователя и пароль при выполнении запроса. При базовой HTTP-аутентификации запрос содержит поле заголовка в форме Authorization: Basic <credentials>, где учетные данные представляют собой кодировку Base64 идентификатора и пароля, соединенные одним двоеточием :.

Он указан в RFC  7617 от 2015 г., который отменяет RFC 2617 от 1999 г. 

Особенности [ править ]

Реализация базовой аутентификации HTTP (BA) - это простейший метод обеспечения контроля доступа к веб-ресурсам, поскольку он не требует файлов cookie , идентификаторов сеансов или страниц входа в систему; скорее, обычная HTTP-аутентификация использует стандартные поля в HTTP-заголовке .

Безопасность [ править ]

Механизм BA не обеспечивает защиту конфиденциальности передаваемых учетных данных. Они просто закодированные с Base64 в пути и не зашифрованы или хэшируются каким - либо образом. Поэтому базовая аутентификация обычно используется вместе с HTTPS для обеспечения конфиденциальности.

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

HTTP не предоставляет веб-серверу метод, позволяющий клиенту «выйти из системы». Однако существует ряд методов для очистки кешированных учетных данных в определенных веб-браузерах. Один из них - перенаправление пользователя на URL-адрес в том же домене с использованием намеренно неверных учетных данных. Однако такое поведение несовместимо между различными браузерами и версиями браузеров. [1] Microsoft Internet Explorer предлагает специальный метод JavaScript для очистки кэшированных учетных данных: [2]

< скрипт > документ . execCommand ( 'ClearAuthenticationCache' ); </ скрипт >

В современных браузерах кэшированные учетные данные для базовой проверки подлинности обычно очищаются при очистке истории просмотров. Большинство браузеров позволяют пользователям специально очищать только учетные данные, хотя эту опцию может быть трудно найти, и обычно очищает учетные данные для всех посещаемых сайтов. [3] [4]

Протокол [ править ]

Сторона сервера [ править ]

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

Для неаутентифицированных запросов, сервер должен возвращать ответ, заголовок содержит HTTP - 401 Несанкционированное статус [5] и WWW-Authenticate поле. [6]

Поле WWW-Authenticate для базовой аутентификации построено следующим образом:

WWW-Authenticate: Basic realm="User Visible Realm"

Сервер может выбрать включение параметра кодировки из RFC 7617 : [1] 

WWW-Authenticate: Basic realm="User Visible Realm", charset="UTF-8"

Этот параметр указывает, что сервер ожидает, что клиент будет использовать UTF-8 для кодирования имени пользователя и пароля (см. Ниже).

Клиентская сторона [ править ]

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

Поле заголовка авторизации построено следующим образом: [7]

  1. Имя пользователя и пароль объединяются одним двоеточием (:). Это означает, что само имя пользователя не может содержать двоеточие.
  2. Результирующая строка кодируется в последовательность октетов. Набор символов, используемый для этой кодировки, по умолчанию не указан, если он совместим с US-ASCII, но сервер может предложить использовать UTF-8, отправив параметр charset . [7]
  3. Результирующая строка кодируется с использованием варианта Base64 (+ / и с заполнением).
  4. Затем к закодированной строке добавляется метод авторизации и пробел (например, «Базовый»).

Например, если браузер использует Aladdin в качестве имени пользователя и open sesame в качестве пароля, то значение поля - это кодировка Base64 для Aladdin: open sesame или QWxhZGRpbjpvcGVuIHNlc2FtZQ == . Тогда Authorization заголовок будет выглядеть следующим образом:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

См. Также [ править ]

  • Дайджест-проверка подлинности доступа
  • HTTP + HTML-аутентификация на основе форм
  • Заголовок HTTP
  • TLS-SRP , альтернатива, если кто-то не хочет передавать серверу эквивалентный паролю (даже зашифрованный, как с TLS).

Ссылки и примечания [ править ]

  1. ^ a b "Есть ли браузер, эквивалентный IE ClearAuthenticationCache?" . StackOverflow . Проверено 15 марта 2013 года .
  2. ^ " Идентификатор команды IDM_CLEARAUTHENTICATIONCACHE " . Microsoft . Проверено 15 марта 2013 года .
  3. ^ «540516 - Удобство использования: разрешить пользователям удалять данные базовой аутентификации HTTP (« Выход »)» . bugzilla.mozilla.org . Проверено 6 августа 2020 . Очистить недавнюю историю -> Активные логины (в деталях) используется для очистки аутентификации.
  4. ^ «Очистить данные просмотра - Компьютер - Справка Google Chrome» . support.google.com . Проверено 6 августа 2020 . Данные, которые можно удалить [...] Пароли: удаляются записи сохраненных вами паролей.
  5. ^ «RFC 1945 Раздел 11. Аутентификация доступа» . IETF. Май 1996. с. 46 . Дата обращения 3 февраля 2017 .
  6. ^ Филдинг, Рой Т .; Бернерс-Ли, Тим ; Хенрик, Фрыстык. «Протокол передачи гипертекста - HTTP / 1.0» . tools.ietf.org .
  7. ^ a b Решке, Джулиан. «Базовая схема HTTP-аутентификации» . tools.ietf.org .

Внешние ссылки [ править ]

  • «RFC 7235 - протокол передачи гипертекста (HTTP / 1.1): аутентификация» . Инженерная группа Интернета (IETF). Июнь 2014 г..