HTTP аутентификация
HTTP предоставляет набор инструментов для контроля доступа к ресурсам и аутентификации. Самой распространённой схемой HTTP аутентификации является «Базовая» (Basic) аутентификация. Данное руководство описывает основные возможности HTTP аутентификации и показывает способы ограничения доступа к вашему серверу с её использованием.
Общий механизм HTTP аутентификации
RFC 7235 определяет средства HTTP аутентификации, которые может использовать сервер для запроса (en-US) у клиента аутентификационной информации. Сценарий запрос-ответ подразумевает, что вначале сервер отвечает клиенту со статусом 401 (Unauthorized) и предоставляет информацию о порядке авторизации через заголовок WWW-Authenticate (en-US) , содержащий хотя бы один метод авторизации. Клиент, который хочет аутентифицироваться, может сделать это, включив в следующий запрос заголовок Authorization с требуемыми данными. Обычно, клиент отображает пользователю запрос (prompt) пароля, и после получения ответа отправляет запрос (request) с пользовательскими данными в заголовке Authorization .
В случае базовой авторизации как на иллюстрации выше, обмен должен вестись через HTTPS (TLS) соединение, чтобы обеспечить защищённость.
Прокси-аутентификация
Этот же механизм запроса и ответа может быть использован для прокси-аутентификации. В таком случае ответ посылает промежуточный прокси-сервер, который требует авторизации. Поскольку обе формы аутентификации могут сосуществовать, для них используются разные заголовки и коды статуса ответа. В случае с прокси, статус-код запроса 407 (Proxy Authentication Required) и заголовок Proxy-Authenticate (en-US) , который содержит хотя бы один запрос, относящийся к прокси, а для передачи учётных данных прокси-серверу используется заголовок Proxy-Authorization (en-US) .
Доступ запрещён
Если (прокси) сервер получает корректные учётные данные, но они не подходят для доступа к данному ресурсу, сервер должен отправить ответ со статус кодом 403 Forbidden . В отличии от статус кода 401 Unauthorized или 407 Proxy Authentication Required , аутентификация для этого пользователя не возможна.
Во всех случаях сервер может предпочесть возвращать код состояния 404 Not Found , чтобы скрыть существование страницы для пользователя без соответствующих привилегий или не прошедшего правильную аутентификацию.
Аутентификация cross-origin изображений
Аутентификация с помощью изображений, загружаемых из разных источников, была до недавнего времени потенциальной дырой в безопасности. Начиная с Firefox 59 (en-US) , изображения, загружаемые из разных источников в текущий документ, больше не запускают диалог HTTP-аутентификации Firefox bug 1423146, предотвращая тем самым кражу пользовательских данных (если нарушители смогли встроить это изображение в страницу).
Кодировка символов HTTP аутентификации
Браузеры используют кодировку utf-8 для имени пользователя и пароля. Firefox использовал ISO-8859-1 , но она была заменена utf-8 с целью уравнения с другими браузерами, а также чтобы избежать потенциальных проблем (таких как Firefox bug 1419658).
заголовки WWW-Aутентификации и Прокси-Аутентификации
WWW-Authenticate (en-US) и Proxy-Authenticate (en-US) заголовки ответа которые определяют методы, что следует использовать для получения доступа к ресурсу. Они должны указывать, какую схему аутентификации использовать, чтобы клиент, желающий авторизоваться, знал, какие данные предоставить. Синтаксис для этих заголовков следующий:
WWW-Authenticate: realm= Proxy-Authenticate: realm=
Здесь, — это схема аутентификации («Basic» (базовая) это наиболее распространённая, представленная ниже). realm используется для описания защищённой области или для индикации области защиты. Это может быть сообщение типа «Access to the staging site» или подобное, чтобы пользователь знал, к какой области он пытается получить доступ.
заголовки Авторизации и Прокси-Авторизации
Заголовки запросов Authorization и Proxy-Authorization (en-US) содержат учётные данные для аутентификации агента пользователя (User Agent) на (прокси) сервере. Здесь снова требуется за которым следуют учётные данные, которые могут быть закодированы или зашифрованы в зависимости от того, какая схема аутентификации используется.
Authorization: Proxy-Authorization:
Схемы Аутентификации
Общая структура HTTP аутентификации является основной для ряда схем аутентификации. Schemes can differ in security strength and in their availability in client or server software.
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, digital-signature-based),
- Mutual (смотреть draft-ietf-httpauth-mutual),
- AWS4-HMAC-SHA256 (смотреть AWS документацию).
Схемы могут различаться по степени безопасности и по их доступности в клиентском или серверном программном обеспечении.
«Базовая» (Basic) схема аутентификации обеспечивает очень низкую безопасность, но широко поддерживается и проста в настройке. Более подробно она представлена ниже.
Базовая (Basic) схема аутентификации
«Базовая» схема HTTP-аутентификации определена в RFC 7617, которая передаёт учётные данные в виде пар пользователь ID/пароль (user ID/password), закодированных с использованием base64.
Безопасность базовой аутентификации
Поскольку идентификатор (ID) пользователя и пароль передаются по сети в виде открытого текста (он кодируется в base64, однако base64 — это обратимое кодирование), схема базовой аутентификации не является безопасной. При базовой аутентификации следует использовать HTTPS/TLS. Без этих дополнительных улучшений безопасности, базовая аутентификация не должна использоваться для защиты конфиденциальной или ценной информации.
Ограничение доступа с помощью 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/
Использование таких URL-адресов устарело. В браузере Chrome в URL-адресах часть username:password@ даже вырезана из соображений безопасности. В браузере Firefox, проверяется, действительно ли сайт требует аутентификации и если нет, тогда Firefox предупредит пользователя запросом (prompt) «You are about to log in to the site «www.example.com» with the username «username», but the website does not require authentication. This may be an attempt to trick you.».
Смотреть также
Found a content problem with this page?
- Edit the page on GitHub.
- Report the content issue.
- View the source on GitHub.
This page was last modified on 27 нояб. 2023 г. by MDN contributors.
Your blueprint for a better internet.
Данные на замке: как двухфакторная аутентификация поможет обезопасить сайт
Пароли, даже самые сложные, уже давно не препятствие для злоумышленников. В ответ на это владельцы сайтов всё чаще вводят второй фактор аутентификации. В этом материале, совместно с нашими партнёрами из WebMoney, мы расскажем о современных способах защиты данных с помощью второго ключа (спойлер: самые популярные — не самые надёжные), а также на примере сервиса E-NUM предоставим инструкцию по бесплатному подключению двухфакторной аутентификации на вашем ресурсе.
Кому и зачем нужна двухфакторная аутентификация
Мы уже давно привыкли получать SMS c числовым паролем от банков при транзакциях и входе в личный кабинет. Банки – яркий пример сферы, где уже давно практикуется двухфакторная аутентификация. Однако не только они нуждаются в безопасном доступе к закрытым зонам своих сайтов. Любой сервис, пользователям которого необходимо постоянно авторизовываться, заинтересован в сохранении собственной репутации и персональных данных клиентов. Это могут быть совершенно разные сайты — от провайдеров сотовой связи до ресурсов с онлайн-играми и обычных интернет-магазинов. Как правило, на таких площадках хранятся персональные данные клиентов.
Особенно привлекательными для хакеров становятся аккаунты, владельцы которых привязали свои банковские карты или уже перевели часть средств на внутренний баланс в личном кабинете. В США некоторые онлайн-магазины начали смотреть в сторону двухфакторной аутентификации, когда выяснилось, что в 2017 году уровень мошенничества в сфере e-commerce вырос на 30% по сравнению с предыдущим годом. Речь идёт как о подмене адреса доставки уже купленных товаров, так и о покупках с помощью украденных банковских карт и других платёжных инструментов. Чтобы сохранить клиента и мотивировать его к повторным покупкам, продавцы начинают задумываться не только об удобстве использования сайта, но и о безопасности и надёжности.
Стоит отметить, что для пользователя двухфакторная аутентификация — это дополнительное действие, отнимающее время. Но резонансные истории о кражах персональных данных постепенно способствуют тому, что второй фактор начинает восприниматься не как препятствия, а как дополнительный уровень защиты.
Какие виды двухфакторной аутентификации есть
Двухфакторная аутентификация постоянно эволюционирует, но само по себе это явление не новое. В свое время были распространены скретч-карты и одноразовые пароли на бумажных носителях.
Одним из самых надёжных способов идентификации считается физический токен, чаще в виде USB-брелоков. Он генерирует криптографические ключи, которые вводятся при подключении к компьютеру. Можно предположить, что этот метод в скором времени трансформируется в NFC-метки на физическом носителе или даже в подкожный чип.
Если уж заглядывать в ближайшее будущее, то в качестве дополнительных факторов защиты всё чаще будет вводиться биометрическая аутентификация по отпечаткам пальцев и фотографии. В рамках мультифакторной аутентификации применяются геолокационные сервисы, верифицирующие пользователя через его местоположение.
Нетрудно догадаться, что самым популярным (но не самым надёжным) вторым фактором стали SMS-подтверждения. Однако для владельцев сервисов отправка SMS связана с финансовыми издержками. Неудобство конечных пользователей в том, что сообщение не всегда приходит мгновенно. Кроме того, злоумышленники могут перехватить его или даже восстановить сим-карту по поддельным документам.
Учитывая доступность Интернета и популярность смартфонов, среди владельцев сайтов сейчас востребованы мобильные приложения для аутентификации.
Одним из первых альтернативных продуктов в сфере двухфакторной защиты стал сервис E-NUM. Его разработка началась в 2007 году. Тогда стояла задача создать решение для двухфакторной аутентификации, которое сочетало бы криптографию, требовало для работы только телефон и не зависело от провайдера связи.
Первая версия E-NUM работала на платформе Java. Сегодня приложение работает на большинстве популярных ОС и генерирует одноразовые ключи по схеме «Вопрос-ответ». «Число-вопрос» не нужно вводить вручную, приложение присылает Push-уведомление после запроса на авторизацию. E-NUM отображает единственно верное «число-ответ» на экране телефона, которое пользователь отправляет, нажав соответствующую кнопку в приложении или введя вручную.
В отличие от некоторых других способов двухфакторной аутентификации, где в качестве подтверждения на телефон клиента приходит готовый «ответ», E-NUM по сигналу из push-уведомления «достаёт ответ» из зашитой в приложении и уникальной для каждого кодовой книги. Она создаётся случайным образом на основе «физических шумов» центрального процессора.
Если пользователю не хочется доставать смартфон и у него есть «умные» часы, то в E-NUM можно подтвердить действие с помощью часов под управлением Apple Watch или Android Wear.
Когда база активных пользователей клиента E-NUM достигла 2,5 млн человек, было принято решение об открытии API. Первоначально сервис E-NUM применялся только в системе WebMoney Transfer. Сейчас владельцам электронных кошельков не обязательно скачивать отдельное приложение, так как E-NUM уже интегрирован в WebMoney Keeper.
На сегодняшний день E-NUM используют более 6 млн человек.
Как настроить двухфакторную аутентификацию на своем сайте
Владельцы сайтов могут бесплатно внедрить систему аутентификации пользователей. Понадобится только запрос на официальном сайте сервиса ENUM.RU и подтверждение заявки.
Выделим два способа интеграции: OAuth2 и Soap.
Метод интеграции OAuth2
Стандарт OAuth 2.0 позволяет предоставить третьей стороне доступ к защищённым ресурсам без необходимости сообщать третьей стороне данные аутентификации пользователя («число-вопрос», «число-ответ»).
Последовательность действий при авторизации с использованием системы E-NUM методом OAuth2 выглядит так:
1. Клиент сайта запрашивает вход в защищённую зону.
2. Для предоставления доступа сайт требует пройти авторизацию, для чего перенаправляет его на E-NUM.
3. После успешной авторизации система E-NUM возвращает клиенту одноразовый код.
4. Браузер клиента, в свою очередь, передаёт код авторизации сайту.
5. Сайт, используя код авторизации, запрашивает у E-NUM временный токен доступа.
6. Этот токен используется в дальнейшем для обращения к методам API E-NUM, которые обеспечивают идентификацию клиента.
Исходный код примера на GitHub
Вы можете реализовать свой OAuth2-клиент E-NUM (согласно описанию методов API) или воспользоваться готовыми клиентскими библиотеками под вашу платформу.
Метод интеграции Soap API
Метод интеграции Soap требует разового перенаправления пользователя на AUTH.ENUM.RU. Последующие запросы уже не требуют перенаправления.
Последовательность действий при авторизации с использованием системы E-NUM методом Soap следующая:
1. Пользователь стороннего сайта вводит свой email. Бекэнд сайта вызывает метод GetChallenge сервиса E-NUM (soap-интерфейс) для получения «числа-вопроса».
2. Сайт отображает «число-вопрос» и просит пользователя ввести «число-ответ». Для проверки ответа пользователя используется метод CheckUserAnswer.
3. При первой авторизации пользователь перенаправляется на https://auth.enum.ru для получения разрешения на работу сайта с Е-NUM в связке с аккаунтом пользователя.
Для использования этого метода владелец сайта должен зарегистрироваться на сайте ENUM.RU.
Напишите в комментариях хотели бы вы видеть больше материалов на тему безопасности. Мы хотим создавать только полезный контент, поэтому нам интересно ваше мнение.
Аутентификация пользователя
Часто сайты должны уметь идентифицировать своих посетителей, чтобы сохранять и показывать им позже какую-либо информацию.
Например, интернет-магазины могут сохранять историю просмотров, чтобы рекомендовать потенциальным покупателям наиболее подходящие им товары. Или агрегатор новостей мог бы предложить пользователям выбирать только интересующие их рубрики.
К счастью HTTP и все браузеры предоставляют возможность сохранения информации о пользователе.
Cookies
Cookies (в дальнейшем просто «куки») — небольшие фрагменты данных, которые веб-сервер отправляет браузеру. Браузер сохраняет их у себя, а при следующем посещении веб-страницы отправляет обратно. Благодаря этому, веб-сервер сможет узнать своего «старого» посетителя.
�� С технической стороны, куки — это обычные HTTP-заголовки.
Когда веб-сервер хочет записать куку в браузер пользователя, он отсылает специальный заголовок ответа с названием Set-Cookie . В этом заголовке должна содержаться необходимая информация и дополнительные аттрибуты, о которых пойдёт речь далее.
В следующий раз, когда браузер пользователя запросит веб-страницу с того же сайта, в числе прочих заголовков браузер передаёт заголовок запроса Cookie . Веб-сервер получит эту информацию, и она будет доступна также и для PHP.
Как установить куки: функция setcookie
Задача очень проста: сохранять и показывать посетителю страницы, сколько раз он посетил наш сайт. Для этого будем сохранять количество посещений в отдельной куке, увеличивая значения на единицу при каждой загрузке страницы.
PHP может управлять заголовками, которые отправляет сервер, а значит, может устанавливать и читать куки.
Чтобы добавить новую куку, необходимо вначале определиться со следующими критериями:
- Название куки (может состоять только из символов латинского алфавита и цифр);
- Значение, которое предполагается хранить;
- Срок жизни куки — это обязательное условие.
За установку куки в PHP отвечает функция setcookie , ей нужно передать как минимум три параметра, описанных выше. Пример:
Обратите внимание, что срок жизни указывается относительно текущей даты. В этом примере кука будет существовать ровно 30 дней с момента установки.
Как прочитать куки
В PHP максимально упрощён процесс чтения информации из cookies. Поэтому все переданные сервером куки доступны в специальном глобальном массиве $_COOKIE .
Так, чтобы получить содержимое куки с именем visit_count , достаточно обратиться к одноимённому элементу массива $_COOKIE , например, вот так:
Обратите внимание: установив в сценарии куку через setcookie , прочитать её можно будет только при следующем посещении страницы.
Собираем всё вместе
Теперь, научившись устанавливать и читать куки, напишем полноценный сценарий, который будет считать и выводить количество посещений страницы пользователем:
setcookie("visit_count", $visit_count, strtotime("+30 days")); print("Количество посещений: " . $visit_count); ?> Сессии
Мы уже умеем сохранять информацию для пользователя между посещениями страницы с помощью кук. Но зачем нам ещё и сессии?
Сессии, они же сеансы, это, по сути, просто удобная обёртка над куками. Они также позволяют хранить данные пользователя, но с некоторыми отличиями и ограничениями:
- Данные хранятся не произвольное время, а только до закрытия вкладки с веб-страницей.
- Чтобы сессии работали, в начале каждого сценария надо вызывать функцию session_start() .
- Доступный объём для хранения информации намного больше.
Запись и чтение информации при использовании сессий выглядит просто как работа со специальным массивом $_SESSION .
Как устроены сессии
- PHP генерирует уникальный идентификатор браузера.
- Идентификатор сохраняется в специальную куку и передаётся с каждым запросом.
- Все данные, которые записываются в сессию, PHP автоматически сохраняет в специальном файле на сервере.
Благодаря существованию сессий в PHP мы можем сохранять любые данные так же просто, как присваивать их переменным. Но, в отличие от переменных, эти данные будут сохраняться для пользователя между запросами в пределах сеанса.
Перепишем сценарий для подсчета посещений, но теперь используем сессии:
$_SESSION["visit_count"] = $visit_count; print("Количество посещений: " . $visit_count); ?> Аутентификация
Представим интернет-магазин. Все его страницы можно разделить на две половины: публичные и приватные.
К публичным относятся страницы каталога, информации о товаре, условия доставки и так далее. К приватным — корзина покупок, история заказов. Совершенно очевидно, что корзина покупок у каждого покупателя должна быть своя, а иметь к ней доступ должен только сам владелец и никто больше.
Проверка доступа пользователей к сайту и называется аутентификацией. Весь процесс аутентификации всегда состоит из нескольких шагов:
- При попытке доступа к закрытой части сайта, пользователь видит форму ввода логина и пароля.
- Форма отправляется, а полученные данные сравниваются с действительным логином и паролем существующего пользователя.
- Если данные совпадают, то пользователь считается аутентифицированным и получает доступ к приватной части сайта.
- При повторном открытии этой страницы пользователь не должен повторно вводить пароль, если он уже делал это в рамках текущего сеанса.
Отличие аутентификации и авторизации
Следует различать два термина: аутентификация и авторизация.
�� Аутентификация — проверка подлинности предоставленного пользователем идентификатора (пара логин-пароль).
Авторизация — процесс проверки и предоставления прав пользователю на выполнение определённого действия.
В примере с интернет-магазином аутентификация выполняется, когда пользователь заполняет форму входа и попадает в свой личный кабинет. Сценарий, обрабатывающий форму, лишь проверяет, что такой пользователь существует, и его пароль совпадает.
Авторизация включается в работу, когда пользователь выполняет какое-нибудь действие. Например, удаляет товар из своей корзины. Во время этого действия сценарий должен проверить принадлежность товара к корзине этого пользователя. Без такой проверки пользователь мог бы удалить товар из чужой корзины.
Логика авторизации намного сложнее, чем простая проверка совпадения почты и пароля при входе на сайт. В авторизацию могут также входить следующие понятия: группы пользователей, виды действий, ресурсы, иерархия ролей и действий. Этой теме можно посвятить отдельную главу, но в рамках этого учебника мы не рассматриваем эту тему.
Использование сессии для контроля доступа
Сессии чаще всего используются для хранения информации о залогиненном пользователе.
Принцип работы простой: внутри сценария, ответственного за обработку формы входа, открывается новая сессия, куда записывается информация о вошедшем пользователе. Такой информацией может быть ассоциативный массив со всеми значениями из соответствующей записи из базы данных.
Затем добавим код, проверяющий существование сессии в сценарии, который должен быть закрыт от анонимных пользователей.
Если сессия пуста, значит, пользователь не выполнял вход на сайт и доступа к данной странице не имеет. В этом случае можно вернуть код ответа 403 и показать сообщение об ошибке, либо принудительно выполнить переадресацию на главную страницу.
Выход с сайта. Как закрыть сессию
Если на сайте есть вход, то должен быть и выход. Таким выходом будет специальный сценарий, который очистит сессию и переадресует на главную страницу.
Чтобы очистить сессию, достаточно очистить массив $_SESSION : $_SESSION = []
«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.
Настройка авторизации через Google
Как настроить авторизацию посетителей сайта через Google в личном кабинете и для оформления заказа
Если у вас несколько сайтов, то авторизацию нужно настроить отдельно для каждого сайта.
- Зарегистрируйтесь в «Гугле».
- Откройте страницу https://console.cloud.google.com/cloud-resource-manager.
- Создайте новый проект кнопкой «CREATE PROJECT».
- Введите любое название и нажмите на кнопку «CREATE».
- Перейдите к настройкам созданного проекта.
- Откройте раздел «Explore and enable APIs».
- Откройте раздел « OAuth consent screen».
- Выберите «User Type → Externanl» и нажмите на кнопку «CREATE».
- На шаге «1. OAuth consent screen» введите название приложения, которое будет видно посетителям во время авторизации на вашем сайте через Google, и email-адрес, по которому пользователи смогут обращаться к вам с вопросами.
- Внизу страницы в секции «Authorized domains» добавьте доменное имя своего сайта.
- В секции «Developer contact information» введите email-адрес, на который Google будет отправлять вам информацию об изменениях в работе этого проекта.
- Нажмите на кнопку «SAVE AND CONTINUE».
- На шагах «2. Scopes» и «3. Test users» нажмите на кнопку «SAVE AND CONTINUE».
- Откройте раздел « Credentials ».
- Нажмите на кнопку «CREATE CREDENTIALS» и выберите «OAuth client ID».
- Выберите тип приложения «Web application».
В поле «Authorized redirect URIs » введите адрес вида https://mydomain.com/oauth.php?provider=google. Замените mydomain.com на домен своего сайта. 
Нажмите на кнопку «CREATE».
- Откройте свой сайт в режиме браузера «инкогнито». Или в другом браузере, где вы не авторизованы ни в своем Вебасисте, ни в «Гугле».
- Перейдите по ссылке «Вход».
- Щелкните по иконке «Гугла».
- Введите данные для входа в сервис.
- После обновления страницы откроется личный кабинет зарегистрированного посетителя вашего сайта.
Готово! Авторизация через Google настроена.
4 комментария
+2
Павел Горелов Разработчик 18 апреля 2022 18:26 #
Сейчас всех заставляют использовать HTTPS иначе работать не будет
https://console.cloud.google.com/apis/credentials?project=parserposter
Ну хоть ключ каждый год не заставляют обновлять как у Yandex