5. Проверка Second-Order

В чем заключается главная особенность инъекции второго порядка (Second-Order)?

Она работает только при втором обращении к сайту База данных сама присылает ошибку со второго раза Внедренный код (Payload) сначала сохраняется в базу данных (через безопасный запрос), а затем используется небезопасно в другом месте приложения Хакер использует сразу два компьютера для атаки

Какой первый шаг (Step 1) в классической Second-Order атаке?

Ввод пароля администратора Регистрация или сохранение данных с "ядовитым" именем, например admin'-- Удаление логов сервера Использование SELECT pg_sleep(5)

Что происходит на втором шаге (Step 2) Second-Order атаки, когда атака "выстреливает"?

Хакер просто видит своё имя в профиле Ничего не происходит, если база данных на Linux При получении из базы данных "ядовитого" имени и его подстановке в другой SQL-запрос через fmt.Sprintf, база воспринимает его как часть кода (например, комментарий --) Сервер Go автоматически блокирует хакера

Почему "Ошибки двойного доверия" (Double Trust) так опасны в Go-разработке?

Потому что Go не доверяет базе данных по умолчанию Потому что разработчик ошибочно считает, что "Данные из базы уже безопасны", и перестает использовать плейсхолдеры (? или $1) при работе с ними Потому что база данных доверяет только Python-разработчикам Это ошибка компилятора Go

Какое "Золотое правило" позволяет полностью исключить риск инъекций второго порядка в вашем Go-коде?

Использовать только PostgreSQL Проверять данные на входе регулярными выражениями НИКОГДА не конкатенировать SQL-строки и не использовать fmt.Sprintf для запросов. Все данные (включая те, что из БД) — только через Prepared Statements (плейсхолдеры ?/$1) Удалять все комментарии -- в текстах пользователей

Где в Go-приложении чаще всего прячется уязвимость к Second-Order SQLi?

В функции main() В конфигурационном файле yaml В модулях Личного кабинета, Логирования или Отчетов, где данные пользователя достаются из базы для изменения или отображения В CSS-файлах

Верно ли утверждение: "Использование Prepared Statements при ПЕРВОМ сохранении данных (INSERT) полностью защищает меня от Second-Order SQLi"?

Да, подготовленный запрос очищает данные Да, в PostgreSQL это именно так НЕТ, данные сохранятся в базу именно в "ядовитом" виде (admin'--). Защита нужна при КАЖДОМ ПОСЛЕДУЮЩЕМ использовании этих данных в других запросах Нет, Prepared Statements вообще не влияют на безопасность