🕸 Веб-аутентификация: файлы cookies или токены?

Перевод публикуется с сокращениями, автор оригинальной статьи Chameera Dulanga.

Cookie-Based Authentication

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

Чтобы лучше понять, как работают файлы cookie, разобьем этот процесс на 5 частей.

1. Пользователь входит в приложение со своими учетными данными

2. Сервер проверяет учетные данные и создает сеанс в базе данных

3. Сервер отправляет файл cookie браузеру, включая его в заголовок Set-Cookie

В дополнение к этому в cookie могут храниться такие сведения, как дата истечения срока действия, домен и возраст. Пример ответа с несколькими заголовками cookie будет выглядеть следующим образом:

        HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<number>
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain>
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path>
Set-Cookie: <cookie-name>=<cookie-value>; Secure
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly

[page content]
    

4. Браузер сохраняет cookie в хранилище и отправляет его с последующими запросами

Найти все сохраненные в браузере файлы cookie можно в хранилище файлов cookie в разделе приложения с помощью инструментов разработчика (devtools).

5. Когда пользователь выйдет из системы, сервер удалит сеанс из базы данных

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

Мы разобрались, как работает аутентификация на основе cookie, теперь рассмотрим фичи, плюсы и минусы этой схемы.

Это полностью автоматизированный процесс

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

Кроме того, при CSRF-атаке злодеи могут воспользоваться этим механизмом, чтобы заставить браузер отправить запросы с cookie на мошеннические сайты.

Безопасность

Cookie не имеют надежной защиты от атак, и они в основном уязвимы для атак с использованием межсайтового скриптинга (XSS) и подделки межсайтовых запросов (CSRF).

Например, куки могут быть легко защищены от XSS-атак с помощью атрибута HttpOnly при настройке заголовков:

        Set-Cookie: <cookie-name>=<cookie-value>; Secure
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
    

Кроме того, можно использовать атрибут SameSite в заголовке файла cookie для эффективного предотвращения CSRF-атак.

        Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
    

Есть 3 значения, которые можно использовать для атрибута SameSite:

• SameSite = Lex гарантирует, что браузер не будет отправлять файлы cookie по межсайтовым запросам (это поведение по умолчанию, если атрибут SameSite не определен).
• SameSite = Strict будет следить за тем, чтобы браузер отправлял cookie только для запросов с того же сайта.
  
• SameSite = None позволит отправлять куки как с межсайтовыми, так и с внутрисайтовыми запросами.
  

Обычно работают в одном домене

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

Если ваш фронтенд и бэкенд лежат в разных доменах или поддоменах, необходимо явно указать это в файле cookie в белом списке. В противном случае браузер не отправит куки вместе с запросом.

Не подходит для API

Например, если вы разрабатываете мобильное приложение, наличие файлов cookie усложнит управление файлами по сравнению с токеном.

Могут возникнуть проблемы с масштабируемостью

Хотя существуют хорошо зарекомендовавшие себя способы управления масштабируемостью (например, использование для хранения сеансов СУБД наподобие Redis), это все равно добавляет сложности. По мере роста количества пользователей, могут возникнуть проблемы с масштабированием и управлением сеансами.

Подходит для хранения дополнительных данных

С помощью файлов cookie и сессий можно хранить дополнительные данные персонализации, контроля доступа и сами сессии – это позволяет использовать их для последующих запросов.

Это не имеет смысла, если речь идет об одном запросе, но преимущества становятся заметны, когда все агрегируется и масштабируется.

Аутентификация на основе токенов

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

Стандартные реализации токен-подхода в разы сложнее описанных выше. Например, в OpenID Connect применяется несколько потоков аутентификации для различных сценариев использования. Чтобы лучше понять, как работают токены, разобьем процесс на четыре части и в качестве примера используем JWT (JSON Web Token) – наиболее широко используемый стандарт.

1. Пользователь входит в приложение со своими учетными данными

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

При передаче обычно необходимо использовать шифрование (например, SSL) для защиты канала.

На стороне сервера можно использовать библиотеку NPM (такую как jsonwebtoken) для создания токенов:

        // Install
npm install jsonwebtoken
// Usage
var jwt = require('jsonwebtoken');
var token = jwt.sign(
              { data: user}, 
              privateKey, 
              { algorithm: 'RS256'},
              exp: Math.floor(Date.now() / 1000) + (60 * 60),            );
    

Сгенерированный с помощью jsonwebtoken токен будет выглядеть следующим образом:

        eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
    

Токен состоит из 3 частей: header, payload и signature (header.payload.signature). Они разделены символом ., и вы можете использовать этот сервис для анализа информации.

3. Сохранение токена в хранилище браузера и добавление в запросы с помощью JavaScript

Браузер может хранить этот маркер в локальном хранилище, хранилище сеансов или в хранилище cookies. Затем он будет добавлен в заголовок авторизации и отправлен на сторону сервера для валидации запросов.

        Authorization: Bearer <token>
    

Кроме того, можно использовать функцию jwt.decode() из библиотеки jsonwebtoken для декодирования токена.

4. При выходе пользователя из системы токен вручную удаляется из хранилища

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

Это stateless-механизм

В отличие от cookie-подхода, вариант с токенами не имеет состояния. Это означает, что он не сохраняет никакой информации о пользователях в базе данных или на сервере. Сервер отвечает только за создание и проверку токенов, что позволяет реализовывать более масштабируемые решения.

Проблемы безопасности

Хотя введением токенов пытаются решить проблемы безопасности аутентификации на основе cookies, полностью от них не избавиться.

Токен не имеет состояния и если он установлен снаружи, то его невозможно отозвать до истечения срока жизни. Поэтому важно, чтобы он имел минимальный срок годности.

Заключение

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

Спасибо за внимание!

Дополнительные материалы:

• Примеры атак XSS и способов их ослабления
• 7 шагов для хакерской атаки на ближайшие точки Wi-Fi
  
• Защита системы Linux: 11 советов по безопасности
  
• Защита от темных сил: Межсайтовая подделка запроса
  
• Offensive или Defensive Security: что лучше, защита или нападение?