6. Финальный тест: SQL Injection

Какой метод защиты является фундаментом (основой) при борьбе с SQL-инъекциями в Go?

Web Application Firewall (WAF) Blacklist фильтрация ввода Prepared Statements с параметризованными запросами Ручное экранирование кавычек через strings.ReplaceAll

Компания использует GORM для всех запросов к БД. Разработчик написал: `db.Raw("SELECT * FROM users WHERE role = '" + role + "'").Scan(&users)`. Это безопасно?

Да, GORM автоматически экранирует все запросы Да, Raw() внутренне использует prepared statements Нет, Raw() с конкатенацией строк уязвим к SQL-инъекции Зависит от версии GORM

Для защиты ORDER BY от инъекций в Go необходимо:

Использовать prepared statements: db.Query("SELECT * FROM t ORDER BY ?", col) Экранировать имя колонки: strings.ReplaceAll(col, "'", "''") Использовать whitelist допустимых значений Обернуть имя колонки в двойные кавычки

При Second-Order SQL-инъекции (Модуль 7) ключевая ошибка разработчика заключается в:

Отсутствии валидации ввода при первоначальном сохранении данных Использовании данных из БД в SQL-запросах без параметризации Отсутствии WAF на сервере Неправильной настройке CORS

Инцидент с TalkTalk (2015) продемонстрировал, что:

Даже простейшие SQL-инъекции могут привести к масштабным утечкам WAF полностью защищает от всех типов инъекций SQL-инъекции возможны только через POST-запросы Только опытные специалисты способны эксплуатировать SQL-инъекции

Какая комбинация мер обеспечивает защиту от Time-based Blind SQL-инъекций?

Только WAF Prepared Statements + context.WithTimeout Rate Limiting + Blacklist Только Network Policies

При code review Go-кода вы нашли строку: `grep -rn 'fmt.Sprintf.SELECT' --include=".go"` вернул 3 совпадения. Какое действие наиболее правильное?

Отклонить PR — любое использование fmt.Sprintf с SELECT опасно Проверить каждое совпадение — опасна только подстановка пользовательского ввода Игнорировать — fmt.Sprintf безопасен для SQL Заменить все на strings.ReplaceAll для экранирования