💫 Поиск с необезвреженным 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

📌 Разбор хакер-челленджа

Самый реалистичный исход — экстракция данных (SELECT). У сервис-аккаунта только SELECT, stacked-queries отключены, но через UNION, логический или time-blind SQL можно вытянуть таблицы, доступные пользователю.

⚠️ Вторичная угроза — second-order инъекция.
Параметр q логируется в audit.log. Если эти логи потом обрабатываются в другом контексте (например, парсером с привилегиями), payload может «проснуться» позже.

Менее вероятные сценарии:
— DoS ограничен statement_timeout=5s и rate-limit;
— модификация данных невозможна при read-only правах.

ℹ️ Что стоит проверить:

— права аккаунта (SELECT ли реально?);
— audit-логи на SQL-паттерны;
— slow-queries и аномалии latency;
— сигнатуры вроде UNION, INFORMATION_SCHEMA, pg_sleep.

ℹ️ Быстрые фиксы:

1. перейти на параметризованные запросы;

2. убрать логирование сырого q;

3. ограничить объём выдачи и частоту запросов;

4. ввести базовые правила WAF и проверки ввода.

Самое важное — не забывайте про second-order: SQLi, спрятанная в логах, — это бомба замедленного действия.

🐸 Библиотека хакера

#ctf_challenge