Инъекции второго порядка: Механика замедленного взрыва

Инъекция второго порядка (Second-Order SQLi) — это своего рода «бомба замедленного действия». В отличие от классических атак, вредоносный код попадает в вашу базу данных абсолютно легально (например, через надежный Prepared Statement), но срабатывает значительно позже. Это происходит в тот момент, когда приложение извлекает эти данные из базы и использует их небезопасно в другом SQL-запросе.

Этот класс уязвимостей особенно коварен потому, что разработчик и pen-tester видят защищённый INSERT и считают endpoint безопасным. Защита через Prepared Statements в момент сохранения создаёт ложное чувство безопасности. Уязвимость проявляется через несколько слоёв бизнес-логики, иногда — через дни или недели после первоначального сохранения, когда сохранённое значение читается другим endpoint'ом и подставляется в небезопасный SQL.

Аналогия: представь склад товаров. На входе у вас идеальный контроль качества — каждая коробка проверяется, маркируется, проходит карантин 24 часа. Но на выходе со склада никто не проверяет содержимое коробок повторно — они уже «свои», прошли входной контроль. Если злоумышленник заложил бомбу в коробку до входа на склад (или взорвал заряд изнутри после прохождения карантина), на выходе он получает результат. Second-Order SQLi работает так: данные «своих» (из собственной БД) принимаются как доверенные, без повторной валидации.

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

---

1. Понятие "Двух шагов"

В обычной инъекции атака происходит мгновенно в рамках одного запроса. В Second-Order атаке процесс разделен на две фазы:

1. Шаг 1: Сохранение (Injection). Хакер регистрируется в системе с именем admin'--. Сервер использует Prepared Statement и корректно сохраняет это имя в таблицу пользователей. Никаких ошибок на этом этапе не возникает.
2. Шаг 2: Срабатывание (Trigger). Позже хакер заходит в личный кабинет и инициирует действие — например, смену пароля. Сервер достает из базы ранее сохраненное имя admin'-- и подставляет его в новый SQL-запрос через конкатенацию или fmt.Sprintf.

---

2. Момент "Взрыва" в Go-коде

Рассмотрим пример уязвимого хендлера смены пароля:

func changePasswordHandler(w http.ResponseWriter, r *http.Request) {
    // 1. Извлекаем логин текущего пользователя из базы
    // username будет равен "admin'--"
    username := getUsernameFromDB(currentUserID) 
    
    // 2. ❌ КРИТИЧЕСКАЯ ОШИБКА: Доверие данным из собственной БД
    query := fmt.Sprintf("UPDATE users SET password = '%s' WHERE username = '%s'", newPass, username)
    
    // 3. База данных выполняет итоговый SQL:
    // UPDATE users SET password = '...' WHERE username = 'admin'--'
}

Результат: Вы только что сменили пароль настоящему администратору, поскольку спецсимволы в имени admin'-- «отрезали» остальную часть SQL-запроса комментариями.

Похожие сценарии: profile-page (где username из БД выводится в SELECT * FROM posts WHERE author = '<username>'), email-notifications (где email из БД попадает в раздел получателей через конкатенацию), audit-logs (где user-agent или browser fingerprint из cookies сохраняется без проблем, а потом читается в analytics-запрос). В каждом случае первоначальное сохранение защищено, а downstream-чтение нет — это и есть Second-Order.

---

3. Таблица работы: Сохранение vs Использование

Фаза	Действие Go-сервера	Результирующий SQL	Статус
1 (SAVE)	INSERT ... VALUES (?)	VALUES ('admin''--')	🟢 БЕЗОПАСНО
2 (USE)	db.Exec(fmt.Sprintf(...))	... WHERE name='admin'--'	🔴 ВЗЛОМАНО

---

4. Почему Second-Order сложно обнаружить

Такие атаки практически невозможно отследить «на лету» с помощью стандартных средств защиты (WAF). Для системы регистрации имя admin'-- выглядит просто как странный набор символов. Инъекция активируется гораздо позже, глубоко внутри бизнес-логики приложения, где проверки часто менее строгие.

---

Настоящая безопасность требует тотального недоверия к любым данным, даже если они поступили из вашей собственной, казалось бы, проверенной базы данных.

Далее мы рассмотрим типичные сценарии, в которых чаще всего прячутся уязвимости второго порядка: от личных кабинетов до систем логирования.