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

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

Обратите внимание: управление сессиями отличается от OAuth, т. к. последний является протоколом делегирования.

Почему безопасность сессий важна?

В любой системе типа «клиент-сервер» неправильная защита приведёт к уязвимости учётных записей для НСД. OWASP (ведущий орган по безопасности) считает неправильно реализованную авторизацию/аутентификацию вторым по величине риском для безопасности приложений. Несколько известных прецедентов хорошо показывают всю серьёзность вопроса:

• Взлом базы данных Docker ранее в этом году привёл к краже токенов доступа GitHub.
• Из-за уязвимости GitLab все токены авторизации пользователя были выставлены в URL, не имели срока действия и были подвержены атакам грубой силой (brute force) из-за короткой длины.
• Программная ошибка позволила украсть токены доступа, что затронуло 90 миллионов учётных записей Facebook.

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

JWT и непрозрачные токены

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

Веб-токен JSON

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

Плюс JWT — это масштабируемость. Бэкенду не нужно выполнять поиск по базе данных для каждого вызова API.

Недостатком является то, что отзыв одного токена по требованию (до истечения срока его действия) может быть затруднён, если не используются методы вроде внесения в чёрный список, которые влияют на масштабируемость решения. Однако можно отменить все токены, изменив ключ подписи.

Непрозрачный токен

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

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

Распространённые атаки на сессии

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

• для атаки посредника;
• для кражи токенов OAuth;
• для XSS;
• для CSRF;
• для доступа к базе данных / файловой системе;
• для фиксация сессии;
• для атаки грубой силой (brute force);
• для социальной инженерии / физического доступа.

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

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

Рассмотрим каждый вид атаки подробнее.

Обнаружение кражи аутентификационных токенов

Предотвращение — это первая линия защиты: должны быть приняты все возможные меры, чтобы снизить шанс воровства. Однако аутентификационные токены относительно часто подвержены краже из-за того, что передаются ненадёжной стороне (интерфейсу приложения), поэтому обнаружение кражи играет важную роль в безопасности. Существующие методы обнаружения основаны на эвристических алгоритмах вроде отслеживания внезапных изменений IP-адресов и следов браузера (или мобильного устройства), а также маркировка «необычного поведения пользователя». К несчастью, эти методы могут быть неточными, их легко подделать и сложно реализовать. Однако есть надёжный способ интегрировать обнаружение кражи в поток управления сеансом.

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

Общие способы реализации управления сессиями

Наиболее часто используемые потоки управления сессиями и их классификация:

• долгоживущий токен доступа;
• краткосрочный/среднесрочный токен доступа, используемый для получения нового токена доступа;
• краткосрочный/среднесрочный токен доступа, использование которого продлевает срок его действия;
• краткосрочный токен доступа;
• краткосрочный токен доступа с долгоживущим токеном обновления.

Долгоживущий токен доступа

Особенности:

• Если пользователь добровольно выходит из системы, токен доступа аннулируется и удаляется на фронтенде.
• Токен авторизации постоянно открыт в трёх пространствах для атаки — фронтенде, бэкенде и во время передачи.
• В случае кражи злоумышленник будет иметь несанкционированный доступ к учётной записи жертвы до истечения срока действия токена, который может составлять недели или месяцы.
• Хищение может быть обнаружено только с помощью эвристических алгоритмов или если пользователь уведомит поставщика услуги.
• Если поток реализован с использованием JWT, токен сложно отозвать. Однако токены Opaque легко могут быть отозваны.

Кратко-/среднесрочный токен для получения нового токена доступа

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

Особенности:

• Токен авторизации постоянно открыт в трёх пространствах для атаки — фронтенде, бэкенде и во время передачи.
• Для поддержания несанкционированного доступа злоумышленник должен постоянно обновлять свой токен.
• Чтобы оставаться в системе, и злоумышленник, и жертва должны запросить у сервера новый токен доступа пока действует текущий (украденный) токен. Оба будут делать это, используя один и тот же токен доступа, поэтому если он используется для запроса дважды, то система может определить, что произошла кража (зависит от реализации фронтенда).
• Сокращённый срок действия токена доступа позволит быстрее обнаружить кражу, но может также ухудшить пользовательский опыт из-за повторяющихся выходов из системы.
• Если обнаружена кража, маркер доступа необходимо отозвать. В случае с JWT может быть сложно остановить атаку.

Кратко-/среднесрочный токен доступа, использование которого продлевает срок его действия

Особенности:

• Если пользователь добровольно выходит из системы, токен доступа аннулируется и удаляется на фронтенде.
• Токен авторизации постоянно открыт в трёх пространствах для атаки — фронтенде, бэкенде и во время передачи.
• Пока жертва/злоумышленник активны, злоумышленник сможет поддерживать несанкционированный доступ.
• Кража токена может быть обнаружена только с помощью эвристических алгоритмов или если пользователь уведомит поставщика услуги.
• После обнаружения маркер доступа необходимо отозвать. При использовании JWT может быть сложно остановить атаку.

Краткосрочный токен доступа

Особенности:

• Если пользователь добровольно выходит из системы, токен доступа аннулируется и удаляется на фронтенде.
• Здесь нет критических токенов авторизации. Этот метод часто предоставляет учётные данные пользователя во время передачи, что делает их уязвимыми.
• Если токен украден, атакующий сможет наносить урон в течение короткого периода времени.
• Кража токена может быть обнаружена только с помощью эвристических алгоритмов или если пользователь уведомит поставщика услуг.
• Токены доступа не нужно отзывать, поскольку они недолговечны. Однако при необходимости токены доступа Opaque можно отозвать, удалив их из базы данных.

Краткосрочный токен доступа с долгоживущим токеном обновления

Особенности:

• Если пользователь добровольно выходит из системы, токены доступа и обновлений аннулируются и удаляются на фронтенде.
• Токен авторизации (токен обновления) постоянно открыт в двух пространствах для атаки — фронтенде и бэкенде — и время от времени открыт во время передачи.
• В случае кражи злоумышленник будет иметь несанкционированный доступ в течение короткого периода времени (до истечения срока действия токена).
• Злоумышленник может использовать украденный токен обновления, чтобы получить новые токены доступа и пользоваться несанкционированным доступом к учётной записи жертвы долгое время.
• Кража токена может быть обнаружена только с помощью эвристических алгоритмов или если пользователь уведомит поставщика услуг.
• Токены доступа не нужно отзывать, поскольку они недолговечны. При необходимости токены доступа Opaque и токены обновления можно легко отозвать, удалив их из базы данных.

Обнаружить кражу можно при определённых сценариях и реализациях. Например, в одной из реализаций предыдущие токены доступа будут немедленно аннулированы при создании нового токена. Это позволяет системе распознать кражу, когда злоумышленник и жертва находятся в сети одновременно. Если злоумышленник использует токен обновления, токен доступа жертвы будет аннулирован, что заставит жертву запросить новый токен доступа. Это приведёт к другому запросу от злоумышленника и так далее. Если бэкенд обнаруживает короткие интервальные запросы на новые токены, можно сделать вывод, что произошла кража.

Лучшие меры для смягчения атак

Атака посредника

Такая атака возможна при следующих сценариях:

• Использование HTTP или неправильная реализация HTTPS.
  Если приложение не использует HTTPS и безопасные cookie, злоумышленник может подключиться к той же сети, что и жертва, отследить сетевые пакеты и увидеть токены аутентификации в виде простого текста во время передачи. Часто, даже когда приложение имеет сертификат SSL, неправильная реализация может привести к атакам. Например, ESPN.com отправляет файлы авторизации cookie через незащищённый HTTP (по состоянию на 10 мая 2019 года).
• Использование прокси-сервера.
  Многие организации контролируют весь трафик в своей сети — на рабочих местах устройства используют корпоративную сеть Wi-Fi. Компании могут разрешить подключённым устройствам доверять своему сетевому прокси-серверу как центру сертификации SSL в качестве предварительного условия для подключения к сети. Это позволит им (или злоумышленнику) видеть информацию токена аутентификации во время передачи.

Самый простой способ защиты — использовать HTTPS и защищённые файлы cookie во всех приложениях. Но это не предотвращает абсолютно все атаки. Можно предпринять дополнительные меры, используя открытые/закрытые ключи, которые фиксируются на устройстве. Фронтенд и бэкенд будут обмениваться этими ключами во время инициализации, до того, как пользователь войдёт в систему. Для последующей связи данные токена могут быть зашифрованы с использованием открытых ключей. Это уменьшает уязвимость к транзитным атакам, делая их возможными только при начальном обмене открытым ключом.

Кража токена OAuth

Если приложение предоставляет токены доступа/обновления через OAuth, существует риск кражи токенов при взломе серверов сторонних приложений. Решить эту проблему (не полностью) можно используя только краткосрочные токены доступа.

Атаки XSS

Злоумышленник может внедрить JavaScript-код в приложение, запущенное в браузере жертвы. Внедрённый код читает и передаёт токены аутентификации злоумышленнику.

Эту атаку можно легко предотвратить с помощью HttpOnly или файлов Secure cookie для хранения токенов аутентификации. При этом не стоит использовать локальное хранилище для токенов аутентификации, ведь так они доступны через JavaScript.

CSRF

Эта атака не направлена на кражу аутентификационных токенов. Вместо этого она позволяет злоумышленнику использовать текущую активную сессию.

Для предотвращения таких атак обычно требуется использование анти-CSRF токена или SameSite cookie.

Доступ к базе данных/файловой системе

Если злоумышленнику удастся получить доступ к БД/ФС с помощью атаки на базу данных или фактического доступа к серверу, он может получить текущие активные токены авторизации или закрытый ключ JWT/SSL. Кража этих ключей потенциально даже хуже, чем украденные пароли, так как это позволит легко перехватывать сессии, что приведёт к серьёзным последствиям для безопасности. Обратите внимание, что злоумышленник может быть сотрудником организации (особенно в быстрорастущих стартапах, где не всегда установлены все надлежащие средства контроля доступа сотрудников к базе данных/серверу).

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

• Сохраняйте в базе данных только хэшированные версии токенов обновления или доступа, чтобы злоумышленник не смог захватить любую сессию в реальном времени. Эта рекомендация применима ко всем реализациям, описанным выше.
• При использовании JWT вы вынуждены хранить закрытый ключ на сервере, что может привести к краже. Злоумышленник сможет перехватить как текущие, так и будущие сеансы. Чтобы ограничить ущерб, необходимо изменить закрытый ключ, используемый для подписи JWT, и немедленно аннулировать все текущие JWT. Изменение личного ключа не повлияет на взаимодействие с пользователем, поскольку токен обновления будет использоваться для создания JWT, подписанного с новым закрытым ключом.

Фиксация сессии

Это возможно, если есть анонимные сессии в веб-приложении.

Для решения этой проблемы нужно генерировать новый набор токенов аутентификации каждый раз, когда пользователь входит в систему, и аннулировать старые (если таковые имеются). Это делается для каждого устройства, а не для пользователя.

Атака грубой силой

Злоумышленник с достаточными ресурсами может непрерывно «угадывать» токены аутентификации, пока одна из попыток не окажется успешной. Это даст ему доступ ко всем украденным токенам. Защититься можно, используя длинные токены с высокой энтропией.

Социальная инженерия и физический доступ

При физическом доступе к устройству жертвы можно украсть аутентификационные токены несколькими способами:

• Злоумышленник может просто прочитать файлы cookie (даже если они Secure или HttpOnly), проверив страницу приложения, если служба доступна через браузер. В мобильном приложении сделать это сложнее, но всё же возможно.
• В зависимости от реализации потоков сессий приложения злоумышленник может украсть авторизационные токены пользователя даже после выхода жертвы из приложения. На YouTube есть видео 2013 года, где показано, что Twitter не аннулировал cookie даже после выхода пользователя из системы. Как отмечает комментатор, это происходило и в 2016 году.

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

Единственный способ действительно решить проблему — установить обнаружение кражи токенов и позволить пользователям выходить из аккаунта на всех устройствах сразу. Это означает, что есть возможность отменить все токены обновления и доступа для этого пользователя. При этом некоторые методы, которые используют долгоживущие токены JWT, могут быть трудными для реализации.