В этом отчете я делюсь историей о том, как простая страница входа привела к получению полного административного доступа. Всё началось с базовой разведки и превратилось в одну из самых серьезных уязвимостей, которые я обнаружил. Вот как это произошло.
Разведка — поиск с помощью 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 - Хакер
