Вектор атаки на JWT токен

HWDTECH BLOG

Яков Лило, CTO Hello World! Technologies, рассказывает о Json Web Token, безопасности и кибератаках. Все совпадения с реальностью случайны или подтасованы.

16-02-2021

безопасность, JWT токен, атаки

Время чтения: 2 минуты

Обсудить или задать вопрос

Многие атаки строятся на наборе удачно совпавших факторов.

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

JWT невероятно популярен.

И, безусловно, у атак есть такие помощники как:
1. Лень;
2. Экономия;
3. Дедлайны и желание сделать побыстрее.

Основываясь на этих фактах поговорим об одном из векторов атак и как от него защититься.

Многие проекты используют staging-окружение, чтобы протестировать свой продукт. Это абсолютно верное решение.

Иногда staging-окружение имеет свободный доступ, либо степень защиты доступа значительно ниже чем следовало бы. Оставим читателю "на подумать", правильно это или нет. Естественно, url окружения легко предсказать. Желающим поэкспериментировать советую попробовать варианты stg.my-amazing-product.com или staging.my-amazing-product.com. Первый успех?

К тому же, наверняка, на staging есть тестовые пользователи. Соответственно, можно попробовать admin/admin, admin/password, user/password и тд. Либо мы можем зарегистрироваться с интересным нам (атакуемым) логином, либо просто с любым логином, с расчетом на целочисленные инкрементные айдишники.

Давайте, как раз на примере инкрементных айдишников и рассмотрим, как происходит атака.

С вероятностью 99 процентов на stg-окружении пользователей меньше, чем на production-окружении.

Таким образом, после регистрации на stg мы можем получить пользователя с таким же id, какой уже есть на prod-окружении.

С очень высокой долей вероятности, в JWT токене именно id будет использоваться для идентификации пользователя.

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

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

Теперь, чтобы наш пазл сложился, нам нужен последний кусочек. Предположим, что было решено использовать один и тот же приватный ключ на staging и на production. Достаточно частое явление :)

Готово! Мы можем получить токен на stg, и с этим токеном зайти на prod из-под пользователя с таким же id. Атака свершилась.

Что же делать?

Использовать разные приватные ключи на разных окружениях;

Не забывать добавлять домен в токен, и проверять домен на сервере;

Закрывать доступ к stg-окружению;

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

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

Раз в месяц мы делаем рассылку с анонсом новых кейсов и статей, опубликованных на сайте.

Подпишитесь на обновления.