💫 Поиск с необезвреженным q

Сценарий: публичный поиск на сайте принимает параметр 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