Сценарий: публичный поиск на сайте принимает параметр q из формы и подставляет его прямо в SQL-запрос через raw в одном месте. БД — PostgreSQL, подключение идёт под отдельным сервис-аккаунтом с ограниченными правами, stacked queries отключены. Параметр логируется в audit-логе.
❓ Что наиболее правдоподобно произойдёт при отправке специально сформированного q:
🔥 — Экстракция данных (SELECT): через UNION / логические/тайм-блайнд техники можно вытянуть строки из таблиц, которые доступны подключению.
👍 — Блокировка/DoS базы: тяжёлые запросы (cartesian join, рекурсивные CTE, expensive aggregates) загрузят БД и выведут сервис из строя.
❤️ — Модификация данных (INSERT/UPDATE/DELETE): возможно только если права у сервис-аккаунта позволяют изменения — маловероятно при правильно настроенном least-privilege.
👾 — Вторичная инъекция (second-order): полезная нагрузка попадает в логи/доп.таблицы и позже используется в другом контексте с большими правами, что открывает дополнительные риски.
ℹ️ Короткий hint: обратите внимание на права подключения, наличие логирования и поведение реплики — они влияют на вероятность каждого сценария.
🐸 Библиотека хакера
#ctf_challenge