Basic авторизация что это
Базовая HTTP-авторизация – защита от честных людей
Базовая HTTP-авторизация – защита от честных людейАрхив номеров / 2005 / Выпуск №5 (30) / Базовая HTTP-авторизация – защита от честных людей
Алексей Мичурин
Базовая HTTP-авторизация – защита от честных людей
Базовая авторизация используется повсеместно для ограничения доступа к «личным кабинетам», «панелям управления», администраторским веб-интерфейсам, форумам и многим другим веб-ресурсам. Думаю, рядовым пользователям сети будет любопытно узнать, как работает это средство и насколько оно надёжно. Начинающим веб-мастерам будет интересно, как его подключить. А веб-программисты со стажем наверняка задавались вопросом, можно ли усилить защиту.
Basic Authorization под микроскопом
За работу механизма так называемой базовой авторизации (далее просто BA – Basic Authorization) на стороне сервера отвечает не какое-то специфическое ПО, а сам сервер.
Давайте рассмотрим диалог клиента и сервера при попытке получить доступ к конфиденциальной информации.
Когда пользователь впервые пытается получить защищённый документ, щёлкнув мышкой по ссылке, по кнопке в форме или просто набрав URL, браузер (клиент) посылает на сервер самый обычный запрос. Это неудивительно – браузер пока не знает, что доступ к этому документу ограничен. Заголовки HTTP-запроса могут выглядеть приблизительно так:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7)
Но сервер возвращает не обычный ответ с кодом 200 (200 означает, что запрос обработан успешно, ответ отправлен), а сообщение о том, что для получения доступа требуется авторизоваться. Вот возможный набор заголовков ответа:
HTTP/1.1 401 Authorization Required
Date: Tue, 01 Mar 2005 11:30:10 GMT
Server: Apache/1.3.33 (Unix)
WWW-Authenticate: Basic realm=»How about authorization?»
Content-Type: text/html; charset=iso-8859-1
Необычным в нём является статус (первая строка), который равен не 200, как при «нормальном» ответе, а 401. Также в нём имеется поле WWW-Authenticate, сообщающее браузеру детали: авторизация будет проходить по Basic-сценарию, пользователю рекомендуется сообщить указанную фразу.
Вслед за этими заголовками передаётся тело документа, которое браузер пока не отображает, а выдаёт диалоговое окно с просьбой ввести имя и пароль.
Если пользователь откажется от ввода пароля, нажав кнопку «Отмена», то браузер отображает тело полученного документа.
Очень широко распространено заблуждение, что в ответ на отказ от ввода пароля (или после ввода неверного имени/пароля) сервер высылает документ с сообщением об ошибке 401. Это не так! Сервер высылает сообщение 401 всегда, когда запрашивает пароль. Когда пользователь нажимает «Отмена», браузер вообще не обращается к серверу[1] – необходимый документ уже загружен, его осталось только показать пользователю.
Если пользователь ввёл имя и пароль, то сразу после нажатия кнопки «ОК» браузер отправляет эту информацию на сервер в новом запросе, заголовок которого будет примерно таким:
GET /paper/1.html HTTP/1.1
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7)
Authorization: Basic MTox
Как видите, это снова обычный GET-запрос, но теперь сервер получил информацию о пароле и имени пользователя в строке Authorization. Секретная информация не защищена, а просто закодирована методом base64 (RFC 2045). Если декодировать строку MTox, то вы получите имя и пароль, разделённые двоеточием. То есть никакой секретностью тут и не пахнет.
Если имя и пароль удовлетворят сервер, то пользователь получит требуемый документ. Набор заголовков ответа будет выглядеть как обычно:
Date: Tue, 01 Mar 2005 11:41:36 GMT
Server: Apache/1.3.33 (Unix)
Last-Modified: Tue, 01 Mar 2005 11:22:32 GMT
Content-Type: text/html; charset=koi8-r
Если пара имя/пароль не верна, то сервер просто снова выдаст документ-запрос 401, повторно инициируя диалог браузера с пользователем.
После первой авторизации браузер запоминает имя и пароль и сообщает серверу эту информацию при всех последующих обращениях. Сервер больше не будет обрабатывать ошибку 401, а от пользователя не потребуется повторного ввода пароля. Процесс авторизации прошёл успешно, но обратите внимание на то, что в результате не была открыта сессия. Иллюзию непрерывной сессии создаёт браузер, который фактически авторизуется при каждом запросе. К этому существенному недостатку BA мы ещё вернёмся.
Кроме того, практически все современные браузеры оснащены менеджерами паролей и способны сохранять пароли на жёстком диске. Если ваш браузер запомнил ваш пароль неделю назад, то сегодня он может избавить вас и сервер от утомительной процедуры авторизации. Читатель, я думаю, осознаёт всю сомнительность такой «услуги» браузера, ведь всю неделю пароль был подвергнут серьёзной опасности.
Два слова о настройке Basic Authorization
«Минусы» BA рассмотрим чуть позже, а сперва оценим главный её «плюс» – простоту настройки.
AuthName «How about authorization?»
Я не сказал ещё про одну Auth-директиву – это Auth-GroupFile. С её помощью можно задать файл, описывающий группы пользователей. К сожалению, информация о группе пользователя может быть использована только в директиве Require. Поэтому разбиение пользователей на группы практически ничем не расширяет возможности администратора и используется редко.
Защитить паролем можно директорию и с HTML-документами, и с CGI-скриптами, и даже с графикой. Одним словом, абсолютно любую директорию, доступную через Web.
ErrorDocument 401 /путь/документ_или_сценарий
то указанный документ (или результат работы указанного сценария) будет высылаться с ответом 401. Пользователь, как вы помните, увидит этот документ, если откажется от авторизации.
Уязвимости Basic Authorization
Итак, BA страдает практически всеми возможными уязвимостями, какие только можно придумать.
Передача открытого пароля
Как вы видели, пароль и имя пользователя передаются нешифрованными (base64-кодирование никак нельзя назвать защитой). Более того, секретная информация оснащена весьма броской «меткой» – текстом «Authorization», которую легко найти в общем потоке данных. Кроме того, если злоумышленник не смог вычленить из трафика пароли с первой попытки, то ему будут предоставлены новые и новые возможности, ведь имя и пароль передаётся при каждом запросе. Вам остаётся только надеяться, что ваш трафик никто не анализирует. К счастью, большинство пользователей Интернета не имеет возможности просмотра вашего трафика.
Защита от перехвата
Можно ли защититься от перехвата? Нет! По крайней мере до тех пор, пока вы остаётесь в рамках протокола HTTP и механизма BA.
Возможность подбора пароля
Как видите, BA не предоставляет никаких средств, ограничивающих количество неудачных попыток авторизоваться. То есть злоумышленник может сколько угодно подбирать пароль. Хуже всего то, что перебором может заняться любой пользователь Интернета. Конечно, не факт, что он отгадает ваш пароль, но, когда одновременно подбор ведёт множество «агентов», опасность взлома, как вы понимаете, умножается, даже если шансы каждого будут невелики.
Этот недостаток можно частично скомпенсировать, и здесь нам поможет директива ErrorDocument. С её помощью можно назначить CGI-скрипт ответственным за обработку ошибки 401. Например:
ErrorDocument 401 /cgi-bin/401.cgi
Самая простая мера, которую можно реализовать таким образом, – это ведение протокола автризаций. Журнал не избавит вас от атак, но вы хотя бы будете знать о них и об их источнике. А знание – сила.
Конечно, вы можете возразить, что всю необходимую информацию можно собирать в log-файлы сервера. Это так. Пользуясь этими файлами, несложно обнаружить попытки подбора пароля, если у вас один посетитель в день, он один пытается ломать защиту, и вы просматриваете статистику каждый день. Если же в день ваш ресурс посещают сотни пользователей, а попытки взлома случаются раз в год, журналы (хуже! – лишь выжимки из них) вы просматриваете примерно с такой же периодичностью, то обнаружить злоумышленников довольно трудно. Кроме того, на многих хостингах у владельца нет возможности просматривать log-файлы или управлять их форматом. А используя CGI-сценарий, можно не только вести журнал, но и, скажем, формировать e-mail-сообщения администратору в «подозрительных» случаях.
Вот простой пример CGI-сценария, написанного на shell. Он ведёт простой протокол, отмечая в журнале время и имя пользователя при каждой попытке авторизоваться.
HTTP авторизация
HTTP предоставляет набор инструментов для разграничения доступа к ресурсам и авторизацией. Самой распространённой схемой HTTP авторизации является «Basic» (базовая) авторизация. Данное руководство описывает основные возможности HTTP авторизации и показывает способы ограничения доступа к вашему серверу с её использованием.
Общий механизм HTTP авторизации
В случае базовой авторизации как на иллюстрации выше, обмен должен вестись через HTTPS (TLS) соединение, чтобы обеспечить защищённость.
Прокси-авторизация
Этот же механизм запроса и ответа может быть использован для прокси-авторизации. В таком случае ответ посылает промежуточный прокси-сервер, который требует авторизации. Поскольку обе формы авторизации могут использоваться одновременно, для них используются разные заголовки и коды статуса ответа. В случае с прокси, статус-код запроса 407 (Proxy Authentication Required) и заголовок Proxy-Authenticate (en-US), который содержит хотя бы один запрос, относящийся к прокси-авторизации, а для передачи авторизационных данных прокси-серверу используется заголовок Proxy-Authorization (en-US).
Доступ запрещён
Аутентификация с помощью изображений
Аутентификация с помощью изображений, загружаемых из разных источников, была до недавнего времени потенциальной дырой в безопасности. Начиная с Firefox 59, изображения, загружаемые из разных источников в текущий документ, больше не запускают диалог HTTP-аутентификации, предотвращая тем самым кражу пользовательских данных (если нарушители смогли встроить это изображение в страницу).
Кодировка символов HTTP аутентификации
WWW-Authenticate and Proxy-Authenticate headers
WWW-Authenticate (en-US) и Proxy-Authenticate (en-US) заголовки ответа которые определяют методы, что следует использовать для получения доступа к ресурсу. Они должны указывать, какую схему аутентификации использовать, чтобы клиент, желающий авторизоваться, знал, какие данные предоставить. Синтаксис для этих заголовков следующий:
Here, is the authentication scheme («Basic» is the most common scheme and introduced below). The realm is used to describe the protected area or to indicate the scope of protection. This could be a message like «Access to the staging site» or similar, so that the user knows to which space they are trying to get access to.
Authorization and Proxy-Authorization headers
The Authorization and Proxy-Authorization (en-US) request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the type is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.
Authentication schemes
The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.
The most common authentication scheme is the «Basic» authentication scheme which is introduced in more details below. IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS. Common authentication schemes include:
AWS4-HMAC-SHA256 (see AWS docs).
Basic authentication scheme
The «Basic» HTTP authentication scheme is defined in RFC 7617, which transmits credentials as user ID/password pairs, encoded using base64.
Security of basic authentication
As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS / TLS should be used in conjunction with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.
Restricting access with Apache and basic authentication
Restricting access with nginx and basic authentication
Access using credentials in the URL
Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this:
Все о WEB программировании
WEB программирование от А до Я
Заказать сайт:
Социальные сети:
Партнеры:
HTTP Basic Authentication или HTTP авторизация
Доброго времени суток. В данной статье мы остановимся на таком понятии как http basic authentication или http авторизация. Для чего нужна http basic authentication и как настроить http авторизацию. И в качестве примера мы сделаем HTTP авторизацию для админки WordPress. Ну что поехали.
Первое, что мы сделаем – это разберемся с понятием http авторизации.
HTTP authentication
HTTP authentication – это протокол, описанный в стандартах HTTP 1.0/1.1. Работает следующим образом:
Существуют несколько схем http авторизации:
Главное отличие – это уровень безопасности. Мы остановимся на basic – это самая небезопасная схема. Но при использовании HTTPS, является относительно безопасным.
Схема Basic является наиболее простой схемой, при которой логин и пароль передаются в заголовке «Authorization» в незашифрованном виде.
HTTP авторизация для админки WordPress
Если вы используете SSL на своем сайте, то вы можете дополнительно настроить http basic authentication для админки WordPress. А это дополнительная защита.
Небольшое отступление: у меня ОС Windows 10 и OpenServer, который расположен по адресу e:\OpenServer\
Затем перейти на один из сервисов генерации пароля (или воспользоваться утилитой htpasswd у кого Linux), например https://truemisha.ru/tools/htpasswd-generator И сгенерировать пароль
И в него помещаем следующий код:
Сохраняем и проверяем.
При попытке перейти к админке WordPress сервер запросит http авторизацию.
Если мы не введем логин и пароль, то сервер вернет ошибку «Authentication required»
Вводим логин и пароль (Логин: Admin, а пароль: admin)
И нас пустило на стандартную страницу авторизации.
И видео к данной статье:
Заключение
Мы с вами дополнительно защитили админку WordPress http авторизацией. Но помните, что мы использовали http basic authentication, а данный тип передает логин и пароль в незашифрованном виде. Используйте https. А в следующей статье мы рассмотрим как организовать http авторизацию с помощью плагина для WordPress (когда у нас нет доступа к настройкам apache). Так, что не пропускайте выхода новых статей подписавшись: VK, facebook, twitter
Аутентификация и авторизация в микросервисных приложениях
Автор: Вячеслав Михайлов, Solutions Architect
Это вводная часть материала, основанного на докладе, прочитанном мной прошлым летом. Печатный материал предполагает больше информации, т.к. в одном докладе обычно не получается рассказать обо всех деталях.
Что такое аутентификация?
На процессах аутентификации и авторизации основано разделения прав доступа, без которого не обходится ни одно более или менее серьезное приложение. Поэтому понимать, как они происходили раньше и происходят теперь, очень важно, но, прежде чем углубиться в описание технологии, давайте разберемся с ключевыми терминами.
Идентификация — процесс определения, что за человек перед нами. Аутентификация — процесс подтверждения, что этот человек именно тот, за кого себя выдает. Авторизация — процесс принятия решения о том, что именно этой аутентифицированной персоне разрешается делать. То есть, это три разных, последовательных и взаимно не заменяемых понятия. Идентификацию часто подразумевают в составе аутентификации. Самое главное — четко различать аутентификацию и авторизацию.
В ходе аутентификации мы удостоверяемся, что человек, который к нам пришел, обладает доказательствами, подтверждающими личность. В этой статье речь в основном пойдет как раз об аутентификации.
Способы аутентификации
При использовании HTTP-протокола простейший способ аутентификации — Basic access authentication. В принципе этот протокол устарел и уже редко используется в интернете, особенно в незащищенных соединениях, но еще сохраняется во внутрикорпоративных системах, просто потому что некоторые из них созданы достаточно давно. Стоит разобраться, как он работает.
HTTP Basic Authentication
Первым, что при обращении к защищенному ресурсу сервер выдаст пользователю, не имеющему доступа, будет ошибка 401 Unauthorized. При этом ответ также содержит информацию о типе аутентификации (в нашем случае – Basic), который он может принимать, и контекст, в рамках которого эта аутентификация действует (Realm). Пользователь вводит логин и пароль, они упаковываются в Base64 и отправляются на сервер для проверки. Здесь существуют различные опасности. Самая распространенная — угроза man-in-the-middle attack, или атаки посредника, в ходе которой при использовании незащищенного соединения учетные данные могут перехватить злоумышленники в момент передачи от клиента к серверу или обратно.
HTTP Digest Authentication
Следующим этапом развития технологии стала чуть более сложная система HTTP digest authentication, которая исключает передачу учетных данных в открытом виде — здесь для проверки используется MD5-хеш с некоторыми примесями, что позволяет избежать подбора логина и пароля. Конечно, этот алгоритм выглядит более надежным, но и он подвержен целому ряду не самых сложных атак. Например, вот тут можно почитать об атаках более подробно.
Forms Authentication
Позднее появился процесс Forms authentication, при котором аутентификация происходит на более высоком уровне модели абстракции. HTTP-сервер при этом не сообщает об ошибке доступа, а просто перенаправляет неаутентифицированного пользователя на другую страницу. Обычно на этой странице отображаются поля для ввода логина и пароля, после заполнения которых формируется POST-запрос с данными и через защищенный канал направляется на сервер. Серверная сторона в свою очередь возвращает пользователю токен или идентификатор сессии, который сохраняется в Cookies и в дальнейшем используется для доступа к защищенному ресурсу.
Token Authentication
На схеме хорошо видно, как и в какой последовательности приложения обмениваются информацией при использовании аутентификацией по токенам.
На следующей схеме дополнительно отражены те этапы взаимодействия, в которых пользователь принимает непосредственное участие. Этот момент и является недостатком подобной схемы — нам всегда нужен пользователь, чтобы получить доступ к ресурсу.
OAuth2 & Open ID Connect
Дальнейшее усовершенствование процесса понадобилось ввиду того, что токен-аутентификация требует присутствия пользователя в момент получения доступа к защищенному ресурсу. Потому что Identity provider при передаче ему управления будет с пользователем взаимодействовать, запрашивая, например, логин и пароль.
В случае сервиса, который от имени пользователя должен через определенные промежутки времени опрашивать некий третий ресурс, — допустим, получать доступ к списку контактов в социальной сети — токен-аутентификация работать уже не будет. Дело в том, что идентификаторы сессии обычно живут очень недолго, чтобы в случае их перехвата злоумышленники получили доступ к сервису лишь на ограниченное время. Но из-за короткого срока действия токена не хватает, например, на ночной процесс.
В 2006 году в ходе работы над реализацией протокола Open ID для Twitter обнаружилась потребность в новом открытом протоколе авторизации. В 2007 инженеры Google и AOL начали совместную работу над ним, а в 2009 Twitter предложил своим пользователям решение, делегировавшее сторонним сервисам доступ к аккаунтам и основанное на протоколе OAuth. Три года спустя была опубликована новая версия — OAuth 2, упростившая разработку клиентских приложений и получившая целый ряд новых возможностей, среди которых оказалось и обновление токена без участия пользователя. Многие сервисы начали использовать этот протокол еще до его официального утверждения.
Разбираемся детально ху из ху
OpenID 1.0 (2006) & OpenID 2.0 (2007) позволяли приложению(арб) запрашивать у доверенного сервера (authority) проверку пользователя(user). Отличия между версиями для нас несущественны.
Взгляд сверху
Обычно в системах встречаются разные компоненты: пользователи, работающие через браузер, пользователи, взаимодействующие с сервером через мобильные приложения, и просто серверные приложения, нуждающиеся в принадлежащих вам данных, хранящихся на других серверах, доступ к которым осуществляется через Web API.
Single sign-on — технология единого входа — позволяет пользователю переключаться между различными приложениями без повторной аутентификации. Используя SSO можно избежать множественных логинов, так что пользователь просто не будет замечать этих переключений. При этом ситуации, когда в рамках вашей инфраструктуры таких приложений будет больше одного, встречаются постоянно. Технология единого входа особенно удобна в больших энтерпрайз-системах, состоящих из десятков приложений, слабо связанных между собой. Вряд ли пользователи будут довольны, вводя логин и пароль при каждом обращении к системе учета рабочего времени, корпоративному форуму или внутренней базе документов.
В качестве реализации мы рассматриваем протокол OAuth2. В принципе, существуют и другие, например, Kerberos, успешно взаимодействующий с Windows, но в случае гетерогенной сети, в которой существуют компьютеры, использующие и Windows-, и Mac-, и UNIX-системы, использовать проприетарные протоколы зачастую неудобно. Тем более, это касается случаев, когда доступ к вашим сервисам осуществляется через веб — здесь OAuth2 оказывается лучшим кандидатом.
На рисунке выше показано, какие именно протоколы используются при каждом типе взаимодействия.
Как мы знаем из раздела «разбираемся детально ху из ху», OpenID Сonnect нужен, чтобы получить у пользователя его учетные данные и проверить их. OAuth 2.0 нужен, чтобы получать токены доступа и с ними обращаться к ресурсам.
Терминология OAuth2 & OpenID Connect
Сервис выдачи токенов
Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам.
Клиент
Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «Security Token Service» у которого клиент запрашивает токен для доступа).
Пользователь
User — собственно конечный пользователь — человек.
Область (scope)
Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес сервиса выдачи токенов в составе запроса на аутентификацию.
По умолчанию все клиенты имеют возможность запрашивать любые области, но это можно (и нужно) ограничивать в конфигурации сервиса выдачи токенов.
Scopes бывают двух видов:
Запрос на аутентификацию
Authentication/Token Request — процесс запроса аутентификации.
Токен личности
Identity Token — подтверждение аутентификации. Этот токен содержит минимальный набор информации о пользователе.
Токен доступа
Access Token — информация, что конкретному пользователю разрешается делать. Клиент запрашивает Access Token и затем использует его для доступа к ресурсам (Web APIs). Access Token содержит информацию о клиенте и пользователе, если она присутствует. Важно понимать, что есть такие типы авторизации, при которых пользователь в процессе непосредственно не участвует (подробнее об этом в следующей части)
Токен обновления
Refresh Token — токен, по которому STS вернет новый Access Token. В зависимости от режима работы, Refresh Token может быть многоразовым и одноразовым. В случае с одноразовым токеном, при запросе нового Access Token будет также сформирован готовый Refresh Token, который следует использовать при повторном обновлении. Очевидно, что одноразовые токены более безопасны.
Более подробно о составе токенов в разделе «структура токена».
Процесс аутентификации
При обращении пользователя к клиенту, тот перенаправляет пользователя на Open ID Connect Provider, который запрашивает у пользователя логин и пароль. В случае успешного прохождения проверки параметров аутентификации он возвращает назад identity token и access token, с которыми пользователь может обращаться к защищенному ресурсу.
Структура токена
Формат
В реализации OAuth2 используется так называемый jwt-токен, который состоит из трех частей. Допустим, при обращении к Identity provider вы отправляете логин/пароль и в ответ получаете токен. Он будет включать в себя: Header (заголовок), Payload (контент) и Signature (подпись). На сайте jwt.io его можно декодировать и посмотреть содержимое формате JSON. На этом сайте вы также найдете описание правил формирования jwt-токенов.
В том, что токены в процессе обмена передаются незашифрованными, ничего страшного нет. Мы изначально исходим из предположения, что коммуникация происходит по защищенному HTTPS-каналу, и повторное шифрование токена было бы избыточным. Единственное, в чем нам нужно убедиться – то, что токен не был подменен или сфальсифицирован на клиентской стороне, для этого достаточно иметь подпись и проверять ее на сервере. Кроме того, токен не содержит никакой критически важной информации.
Кроме identity tokens, есть еще и аccess tokens, которые содержат информацию о выданных пользователю клеймах. Срок действия access token достаточно короткий, потому что его хищение может обеспечить несанкционированный доступ к ресурсу. Т. е. злоумышленник, если ему удастся заполучить токен этого типа, доступ получит на очень непродолжительное время. Для получения нового access token используется refresh token, который обычно не фигурирует в незащищенных средах, в частности в режиме доступа из браузера он вообще не используется. Какие именно токены будут возвращены клиенту в процессе аутентификации, разберемся в следующей части.
Основные поля
Кратко остановимся на том, какие есть стандартные полях в токене и зачем они нужны:
Заключение первой части
В этой статье мы постарались дать теоретический и терминологический фундамент, который понадобится нам создании работающего решения в следующих статьях.
Минимальная реализация интеграция Identity Server в ваше приложение выглядит так:
Минимальная реализация интеграции веб-клиента с Identity Server:
Минимальная реализация интеграции веб-API с Identity Server: