В этом отчете я делюсь историей о том, как простая страница входа привела к получению полного административного доступа. Всё началось с базовой разведки и превратилось в одну из самых серьезных уязвимостей, которые я обнаружил. Вот как это произошло.

Разведка — поиск с помощью DuckDuckGo

Проводя тестирование в рамках Bug Bounty программы, я использовал некоторые DuckDuckGo dorking техники. Хотя основной сайт возвращал ошибку 403 Forbidden, я нашел архивированную панель входа администратора, проиндексированную поисковой системой.

Открытие этого архивированного URL дало мне доступ к рабочей странице входа администратора — даже несмотря на то, что основной сайт блокировал прямой доступ. На этом этапе я начал тестировать процесс входа.  

Первые попытки — никаких очевидных ошибок

Я попробовал изменить ответ и модифицировать заголовки, но ничего интересного не произошло. Не было ни IDOR, ни неправильных настроек — пока...

Я решил запустить фаззинг путей, чтобы посмотреть соседние со страницей входа директории. Удивительно, но я нашел большое количество конечных точек, которые отвечали HTTP 302 Found, и размер ответов был довольно большим, что указывало на то, что это не пустые редиректы.

Это привлекло мое внимание.

Обход редиректов — ручное тестирование

Я начал вручную модифицировать ответы. После изменения HTTP статусов с 302 на 200 и удаления заголовков, требующих аутентификации, страницы начали отображаться — даже без входа в систему.  

Некоторые страницы содержали отсутствующие данные (что было ожидаемо), но другие позволяли мне взаимодействовать с контентом, включая редактирование определенной информации.  

На этом этапе я оценил проблему как Medium / High, но что-то подсказывало мне, что проблема может оказаться серьезнее — поэтому я не стал спешить и сообщать об этом.

Глубокий фаззинг — JavaScript файлы.

На следующий день я возобновил свой recon. На этот раз я сосредоточился на JavaScript файлах. Приложение использовало отдельный JS файл почти для каждой страницы администратора.

Я просмотрел каждый JavaScript файл и нашел ссылки на чувствительные конечные точки — включая POST операции добавления, редактирования и удаления.  

Я начал дублировать запросы... и они сработали.  

Это повысило уровень серьезности до Высокого — но я на этом не остановился.

Повышение привилегий через параметр role

Углубляясь в детали, я нашел файл с именем ListUsers.js. Он раскрыл конечную точку, которая позволяла создавать и удалять пользователей. Ключевой момент: запрос включал параметр role.  

С помощью DeepSeek я составил запрос на создание нового пользователя и назначил ему роль администратора.

Ответ? Успех.

Я вошел в систему с только что созданной учетной записью — и бах, у меня были полные административные привилегии.

Итоговый Impact

С этой учетной записью я смог получить доступ и управлять:

✅ Рабочими процессами и категориями  

✅ Созданием/удалением сайтов и клиентов  

✅ Контролем доступа на основе ролей  

✅ Пользователями, включая доступ к личной информации более 8,000 сотрудников  

✅ Более чем 270 конфиденциальными внутренними функциями  

В общем, у меня был полный контроль над всем бэкендом системы.

Заключение

То, что началось как забытая страница входа, превратилось в полный захват системы — и все это без каких-либо учетных данных. Это показывает, как архивный контент и неправильно настроенные редиректы могут раскрывать элементы инфраструктуры.

Всегда следите за вашими эндпоинтами и никогда не полагайтесь на то, что 403 = скрытый — иногда это означает «смотрите внимательнее».

Еще больше познавательного контента в Telegram-канале — Life-Hack - Хакер