Как стать администратором веб-приложения за 0 секунд без перебора паролей и эксплойтов ...
Как стать администратором веб-приложения за 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 или что-то левое - библиотека выбросит исключение еще до того, как тело запроса дойдет до бизнес-логики. Практика показывает: даже самые модные технологии становятся решетом, если полагаться на дефолтные настройки библиотек.