Типичные сценарии: Где срабатывает "второй порядок"

Современное веб-приложение на Go состоит из множества модулей: управление профилями, системы логирования, генерация отчетов. Инъекции второго порядка опасны тем, что они могут скрыто «мигрировать» между этими компонентами. То, что начиналось как безобидная регистрация пользователя, может закончиться удалением всей базы данных при обычном обновлении профиля.

Изучим три наиболее распространенных сценария атаки на Go-приложения.

---

1. Сценарий: Смена пароля

Хакер регистрируется под именем admin'--. Позже, используя форму смены пароля в своем кабинете, он провоцирует сервер на выполнение запроса: query := fmt.Sprintf("UPDATE users SET password='%s' WHERE username='%s'", newPass, usernameFromDB)

Итог: Благодаря комментарию -- в сохраненном имени, запрос превращается в директиву смены пароля для пользователя admin. Злоумышленник захватывает аккаунт администратора, просто сменив пароль в собственном профиле.

---

2. Сценарий: Записи в журналах аудита

Представьте, что ваше приложение записывает действия пользователей в таблицу web_logs для последующего анализа:

func auditLog(username string, action string) {
    // ❌ КРИТИЧЕСКАЯ ОШИБКА: Вера в чистоту данных из базы
    query := fmt.Sprintf("INSERT INTO web_logs (user, action) VALUES ('%s', '%s')", username, action)
    db.Exec(query)
}

Если атакующий выберет имя admin'), ('pwned', 'deleted'--, то при каждом его действии в ваш журнал аудита будет внедряться лишняя строка, нарушая целостность логов и скрывая реальные действия злоумышленника.

---

3. Таблица сценариев: От внедрения до срабатывания

Место внедрения (Injection)	Место срабатывания (Trigger)	Последствия
Регистрация	Личный кабинет	Захват чужого аккаунта
Редактирование профиля	Панель администратора	SQLi внутри админки
Настройки компании	Генерация PDF-отчетов	Утечка данных через отчет

---

4. Ошибка "Двойного доверия"

Главная причина успеха таких атак — ложное чувство безопасности у разработчика. Кажется, что если данные уже попали в PostgreSQL, значит, они проверены и им можно доверять. Это опасное заблуждение. Любые внешние данные остаются «ядовитыми» на протяжении всего времени их жизни в системе.

В лабораторной этого модуля точка инъекции — поле Full Name в форме регистрации. Payload сохраняется в БД параметризованным INSERT (на этом шаге всё «безопасно»), но позже срабатывает в другом запросе:

Сначала пользователь сохраняется через параметризованный INSERT — выглядит безопасно, и любой статический анализатор скажет, что код чист. Но позже на странице профиля вступает в силу второй обработчик: он читает fullname из БД и подставляет его в LIKE-запрос через fmt.Sprintf. Именно в этот момент происходит «выстрел» отложенного пейлоада. Конкретный payload в подсказках лабы намеренно не приведён — задача студента собрать его, опираясь на разобранную механику Second-Order и место активации.

---

Инъекции второго порядка могут скрываться в самых неожиданных частях вашего кода. Использование fmt.Sprintf для построения SQL-запросов — это приглашение для хакера.

Перейдем к детальному разбору архитектурной ошибки «двойного доверия» и узнаем, как правильно выстраивать границы безопасности.