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