Встретилось тут на проекте Java веб-приложение старенькое, которое меня неприятно удивило: во всех HTTP-запросах отправлялись не нормальные параметры в разных формах с нормальным API, а координаты моих кликов, а также UUID-кнопок и форм, и отдельные JSON'ы, содержащие данные, которые я заполнял в формах.
По типу такого короче:
POST /myapp/UIDL/?v-uiId=0 HTTP/1.1
Host: localhost:8080
Content-Type: application/json; charset=UTF-8
Cookie: JSESSIONID=...
[
{
"csrfToken": "9f7c2a31-8c6d-4f2e-bbd8-fb1d0aefcb1e",
"rpc": [
[
5, "click", { "button":1, "clientX":123, "clientY":456 }
]
],
"syncId": 7,
"clientId": 7
}
]
Я уже не первый раз видел такое, но раньше попадались приложения, где подобное взаимодействие реализовано не везде, а на части функционала, а тут всё на таком ужасе. Чуть покапавшись, я понял, что приложение было на Vaadin фреймворке. В нём UI полностью описан и хранится на сервере.
Для Vaadin формат взаимодействия описывается так:
1) Браузер получает минимальный HTML+JS (bootstrap клиент), который соединяется с сервером
2) Любые действия пользователя преобразуются в сообщения (обычно AJAX или WebSocket): координатами/идентификатором события, UUID компонента (кнопка, поле формы, таб и т.д.), значением, которое пользователь ввёл, состоянием/ID сессии, чтобы сервер знал, какой пользователь и какой UI-инстанс
3) Сервер принимает это событие, обновляет своё дерево UI и отправляет обратно diff изменений интерфейса, которые надо отобразить на клиенте
Вообщем своего рода толстые серверные приложения с тонким клиентом.
А теперь интересные моменты, которые я для себя выделил, пока работал с ним:
1) Для определения Vaadin'а достаточно найти маршрут, содержащий
/UIDL или /VAADIN/.2) Искать CSRF'ы в приложении с ним почти бессмысленно, так как есть CSRF-токен, но отдельные механизмы могут быть и без него(привет logout, только если это не бб).
3) Иногда может быть доступен дебаг при добавлении
?debug к маршруту(вряд-ли будет супер полезным, но кто знает).4) Если вам надо что-то перебрать автоматизированно, как ту же форму логинки, то тогда берите selenium и в путь, так как даже в их документации указан именно он и другие похожие утилиты.
5) Само тестирование приложения скорее всего у вас будет полностью в браузере, с очень редким поглядыванием в Burp: тыкаем все кнопки, заполняем все формы, вставляем везде нагрузки вручную, отдельно вылавливая HTTP-запросы с нормальным форматом, как например, запросы с загрузкой файла.
6) Если приложение использует Vaadin, то оно скорее всего старенькое(особенно если по js-скрипту вы поймёте что это какая-нибудь 7 версия, что вообщем-то привет из 2013. Понять это можно по GET-параметру
?ver, который добавляется к JS/CSS файлу), так что смело ищем критичные серверные баги: RCE, XXE, SQLI, log4shell и пр. Они 100% будут!7) Также в таких приложениях полно BAC'ов и IDOR'ов, потому отлаживать это - боль для разраба
8) Я хз правда поможет ли, но при обращении к папке
/VAADIN/themes можно найти другие файлы и каталоги, связанные с темами, в которые можно провалиться, возможно там вы тоже сможете что-то найти.В конце очень хочется сказать, что данный пост - это мой опыт BlackBox тестирования веб-приложения с Vaadin, но если вам повезло и у вас WhiteBox, то очень рекомендую данный пост от @rive_n(Канал оказывается стал закрытым, так что можете попросить у автора доступ к Vaadin посту:D )