Самый реалистичный исход — экстракция данных (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