Типовые "грешки" использования JWT

Салют,

Тут недавно пересекался с коллегами, с которыми записывали подкаст по безопасной разработке - инфо тут.

Так вышло, что хотел бы поделиться с вами интересным подходом, чем-то напоминает классическую модель. У этих ребят, занимающихся консалтингом и Compliance, есть обзоры в части рисков ИБ по теме уязвимостей в разработке.

Один из интересных постов вот этот. Автор разбирает обход аутентификации в вебе, описывает вектора атак и как минимизировать их. Прочитав вы можете увидеть, что в зависимости от кейса можем акцентироваться на самом принципе и докрутить.

Давай посмотрим на JWT сессии в том же ключе на примере обычного внедрения

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

JWT (Json Web Token) токен аутентификации пользовательской сессии, то есть самого пользователя для запросов к методам API. Нужен для передачи учетных данных к серверу на каждый вызываемый метод.

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

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

- путем ограничения его временем жизни

- валидация изначально проверяет время жизни токена

- blacklist

- защищенный канал передачи данных

- сброс сессии после конца времени жизни токена в неактивном состоянии

- привязка к action button в случае активности пользователя внутри окна аутентифицированного приложения

- дебажить на jwt.io вне команды разработки для тестов ИБ путем модификации

- не передавать чувствительные пользовательские данные (база)

- использовать ключевые фразы большой длины и их периодическое изменение

- принудительная смена токенов

- на стороне приложения реализовать белый список разрешенных алгоритмов

- санитизировать полученные от пользователей данные

- мы можем просто отозвать токен в любой момент времени, а после его перевыпустить

- дополнительно можем использовать контроль версии

- усилить схему подписи по модели Эскроу

- покрыть солью (salt) в специфичных случаях

Получается, что мы имеем access token - доступ при каждом запросе, refresh token - перевыпуск пары, а также указанное значение жизни по time-delay. Сама структура состоит из данных в payload, header как тип и алгоритм шифрования, cripto signature.

Итого: базово механизм реализует только обновление и передачу, но без доп мер защиты могут быть реализованы атаки по типу:

- отсутствие проверки подписи, где если поставить alg none, сервер неподписанный токен примет в явном виде с payload и права например admin

- манипуляция ключевыми идентификаторами из-за отсутствия сложности key id

- подбор ключа симметричной подписи и подбор ключевой фразы

- для ассиметричных путем изменения алгоритма через hex с использование логических ошибок реализации

- перехват токена и UrlDecode

И да, все-таки стоит посмотреть на коллег и их кейсы в AKTIV.CONSULTING @aktivcons.

#reco #reserch #secrets #pmcases