Как стать администратором веб-приложения за 0 секунд без перебора паролей и эксплойтов базы данных? Ответ кроется в архитектуре JSON Web Tokens (JWT). 🔑

Продолжаю практический марафон на Parrot Security OS. После того как мы сдампили базу пользователей через SQL-инъекцию, я решил проверить, насколько надежно бэкенд верифицирует клиентские сессии. Написал скрипт на Ruby (jwt_forge.rb) и разобрал одну из самых громких уязвимостей спецификации - атаку с алгоритмом none.

Делюсь разбором «на пальцах» и тем, как это выглядит в боевом терминале. 👇

В чем фундаментальная ошибка JWT? 🧩
Токен состоит из трех частей через точку:
Header.Payload.Signature

1. Header: метаданные (каким алгоритмом подписан токен, например RS256).

2. Payload: полезная нагрузка (ID пользователя, email, роль admin).

3. Signature: цифровая подпись сервера, которая гарантирует, что данные не подделаны.

Обе первые части - это обычный открытый текст, закодированный в Base64. Их может прочитать и изменить абсолютно любой человек в браузере. Вся безопасность держится исключительно на третьей части - проверке сервером подписи своим секретным ключом.

Но стандарт RFC предусматривает алгоритм подписи "none" - режим вообще без криптографической проверки.

Механика атаки: срезаем подпись на лету ✂
Если разработчики используют устаревшие библиотеки или забыли жестко зафиксировать разрешенные алгоритмы на бэкенде, сервер совершает фатальную ошибку: он слепо доверяет заголовку, который прислал клиент!

Что делает мой скрипт:

1. Берет легальную структуру токена.
2. В полезную нагрузку (Payload) вписывает права администратора: {"role": "admin"}.
3. В заголовке (Header) подменяет алгоритм на "alg": "none".
4. Начисто удаляет третью часть (подпись), оставляя только точку на конце: Base64(Header).Base64(Payload).

Запрос уходит на сервер через Burp Suite... и бэкенд отвечает статусом HTTP 200 OK!

Сервер прочитал заголовок, решил: «А, тут алгоритм none, значит проверять цифровую подпись не нужно» - и моментально выдал полный административный доступ к базе /api/Users. В Cookie прилетел валидный ответ. Занавес. 🎭

Почему это критично для бизнеса? 💣
В отличие от классических атак на форму входа:

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

Как закрыть эту дыру разработчикам? 🛡
Правило одно, и оно железобетонное: никогда не считывайте алгоритм проверки из заголовка токена клиента.

В коде бэкенда алгоритм верификации должен быть жестко зашит в конфигурации:
jwt.verify(token, secretKey, { algorithms: ['RS256'] })

Если клиент пришлет none, HS256 или что-то левое - библиотека выбросит исключение еще до того, как тело запроса дойдет до бизнес-логики.

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