К специалистам CoreWin обратилась компания Magius. Вопрос состоял в проверке веб-интерфейса, который, на первый взгляд, выглядел как обычный веб-интерфейс с типичной авторизацией.
Первый нюанс – архитектура
Сайт имеет всего одну динамическую страницу, а ее контент собирается сервером на бэкенде в зависимости от запросов пользователя.
Примечание: подобным образом работает подход к созданию архитектуры React, где сервер возвращает данные для отображения, а браузер формирует элементы отображения самостоятельно.
В начале, когда Acunetix сканировал структуру сайта с помощью функции кроулинга – он показал только одну страницу. Это стало причиной неожиданного результата – Acunetix не нашел никаких уязвимостей.
Конечно, такое случается, но вероятность подобной ситуации 1 из 100. Но и это, как правило, временное явление и уязвимости в конце концов появляются, или в процессе доработки сайта, или пока хакеры не находят в системе новые узкие места. Как подтверждение, последний отчет по веб-безопасности от Invicti.
На этом этапе нам стало очевидно, что из-за нетипичного построения ресурса процесс сканирования выполняется некорректно и необходимо найти способ «указать» сканеру на наличие дополнительных компонентов.
В первую очередь мы проанализировали двигатель. Как оказалось соединение клиентской части с бэкенд-сервером происходило по API, а значит, нам нужен был токен для того, чтобы сканер получал к нему доступ.
Здесь следует отметить, что мы всегда рекомендуем импортировать API документацию (API definitions). Однако очень часто встречаются случаи, когда такая документация отсутствует, как это было в случае Magius. По этой причине успешный crawling бэкенда был крайне важным.
Тесты показали успешную авторизацию, и мы ожидали успешного полного сканирования.
Второй технический нюанс заключался в процессе авторизации
Авторизация пользователя и авторизация в API интерфейсе оказалась сквозной, то есть для авторизации в «двигателе» использовался тот самый токен, который подтверждал сессию пользователя.
Соответственно необходимо было указать такие настройки в самом сканере – получать токен сессии при воспроизведении скрипта авторизации и использовать его для сканирования API интерфейса двигателя.
Нам удалось обработать все технические нюансы и успешно выполнить процесс сканирования, несмотря на специфическую архитектуру динамического веб-ресурса.
Итоги
Но этот кейс иллюстрирует, в первую очередь, динамичность развития технологий веб-разработки. Это та сфера, где заученные правила могут только повредить, а неожиданные подходы (как наш кейс) совсем скоро могут стать общепринятыми.
