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

🧩 Хакер-челлендж

Сценарий: Microservice-архитектура с JWT-аутентификацией. Сервис A генерирует токены (алгоритм RS256), сервис B их проверяет. В JWT payload:

{
  "user_id": 1337,
  "role": "user",
  "iat": 1699552800,
  "exp": 1699639200
}

Сервис B проверяет подпись, но разработчик добавил фичу:

Если в заголовке токена указан “alg”: “none”, проверка пропускается для «тестовых» запросов. Также в коде есть fallback на HS256 с секретом из переменной окружения.

Публичный ключ RS256 доступен по эндпоинту /jwks.json.

❓ Какой вектор атаки наиболее эффективен для получения admin-доступа? Голосуйте эмодзи:

🔥 — Algorithm confusion: подменить RS256 на HS256, используя публичный ключ как symmetric secret

👾 — None algorithm bypass: создать токен с “alg”: “none”, изменить role на “admin”

❤️ — JWT secret bruteforce: перебрать HS256 секрет (если он слабый) через hashcat

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

#ctf_challenge