2. Реальные CVE и инциденты с SQL-инъекциями

Реальные CVE и инциденты с SQL-инъекциями

SQL-инъекции остаются одной из самых разрушительных уязвимостей в истории информационной безопасности. Несмотря на то что техника известна с конца 1990-х, она регулярно приводит к масштабным утечкам данных. В этом разделе мы разберём реальные случаи и извлечём уроки, применимые к Go-разработке.

CVE-2008-5817: Heartland Payment Systems

Масштаб: Утечка 130 миллионов номеров кредитных карт — одна из крупнейших в истории на тот момент.

Механика: Атакующие использовали SQL-инъекцию для внедрения вредоносного ПО (sniffer) в систему обработки платежей. Инъекция была входной точкой, через которую злоумышленники получили доступ к внутренней сети.

Урок для Go-разработчиков:

// ПЛОХО: конкатенация в платёжном обработчике
query := "SELECT card_data FROM transactions WHERE merchant_id = '" + merchantID + "'"

// ХОРОШО: параметризация
row := db.QueryRowContext(ctx, "SELECT card_data FROM transactions WHERE merchant_id = ?", merchantID)

SQL-инъекция часто является лишь точкой входа для более масштабной атаки. Даже если ваш конкретный эндпоинт не хранит секретных данных, через него злоумышленник может получить foothold в системе.

CVE-2012-2661: Ruby on Rails (SQL Injection через ORM)

Масштаб: Уязвимость в одном из самых популярных веб-фреймворков, затронувшая тысячи приложений.

Механика: Некорректная обработка вложенных хешей в Active Record позволяла внедрять произвольный SQL через параметры запроса, несмотря на использование ORM.

Урок: ORM не является панацеей. В Go аналогичная проблема возникает при использовании GORM:

// ПЛОХО: динамический where через строку
db.Where("name = '" + userInput + "'").Find(&users)

// ХОРОШО: параметризованный where
db.Where("name = ?", userInput).Find(&users)

// ПЛОХО: raw-запрос в GORM
db.Raw("SELECT * FROM users WHERE role = '" + role + "'").Scan(&users)

// ХОРОШО: raw-запрос с параметрами
db.Raw("SELECT * FROM users WHERE role = ?", role).Scan(&users)

CVE-2014-0160 + SQLi chain: TalkTalk (2015)

Масштаб: Утечка персональных данных 157 000 клиентов. Штраф 400 000 фунтов от ICO (на тот момент — рекордный).

Механика: Атакующие (подростки 15-17 лет) использовали простейшую SQL-инъекцию на устаревшей странице, о которой компания даже не знала. Никакой сложной техники — обычный ' OR 1=1 --.

Урок: Забытые эндпоинты (legacy pages) — одна из самых распространённых точек входа. В Go-проектах это проявляется так:

// Забытый debug-эндпоинт из ранней разработки
mux.HandleFunc("/debug/user-lookup", func(w http.ResponseWriter, r *http.Request) {
    name := r.URL.Query().Get("name")
    // Этот handler написали «временно» 2 года назад...
    rows, _ := db.Query("SELECT * FROM users WHERE name = '" + name + "'")
    // ...
})

Решение: Регулярный аудит роутов, удаление неиспользуемых эндпоинтов, CI/CD проверка на конкатенацию строк в SQL-запросах.

CVE-2019-15107: Webmin (Unauthenticated RCE через SQLi)

Масштаб: Бэкдор в популярном инструменте администрирования серверов, используемом сотнями тысяч организаций.

Механика: Злоумышленник скомпрометировал build-pipeline и внедрил уязвимый код в функцию сброса пароля. Через SQL-инъекцию можно было выполнить произвольные команды на сервере.

Урок для Go: Supply chain security — даже если ваш код безопасен, зависимости могут содержать уязвимости:

// Проверяйте зависимости регулярно
// go list -m -json all | nancy sleuth
// govulncheck ./...

CVE-2021-27928: MariaDB (Second-Order через wsrep_provider)

Масштаб: Полный RCE на сервере базы данных.

Механика: Классический Second-Order: данные сохранялись в конфигурацию, а затем использовались при перезапуске кластера без экранирования.

Урок: Это прямая иллюстрация того, что мы изучали в Модуле 7. Данные, однажды сохранённые в БД, могут быть опасны при повторном использовании:

// Модуль 7 напоминает: prepared statements нужны ВЕЗДЕ —
// и при записи, и при чтении, и при повторном использовании данных из БД

// ПЛОХО: доверие данным из БД
username, _ := getUsernameFromDB(userID)
query := fmt.Sprintf("INSERT INTO audit_log (action) VALUES ('Login by %s')", username)

// ХОРОШО: параметризация даже для данных из БД
db.ExecContext(ctx, "INSERT INTO audit_log (action) VALUES (?)",
    fmt.Sprintf("Login by %s", username))

CVE-2023-34362: MOVEit Transfer (Mass exploitation)

Масштаб: Более 2500 организаций скомпрометированы, включая правительственные структуры, банки и университеты. Группировка Cl0p использовала уязвимость для массового вымогательства.

Механика: SQL-инъекция в функции обработки файловых трансферов позволяла обходить аутентификацию и выполнять произвольные SQL-команды. Атакующие извлекали данные через автоматизированный pipeline.

Урок: Масштаб эксплуатации показывает, почему автоматизированные сканеры (Модуль 10) так опасны — и почему rate limiting и мониторинг критически важны:

// Rate limiting для критических эндпоинтов
limiter := rate.NewLimiter(rate.Every(time.Second), 10)

func transferHandler(w http.ResponseWriter, r *http.Request) {
    if !limiter.Allow() {
        http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
        return
    }
    // ... безопасная обработка запроса с prepared statements
}

Статистика: SQL-инъекции в цифрах

• OWASP Top 10 (2021): Injection-уязвимости переместились с 1-го на 3-е место (A03:2021), но остаются в топе
• Verizon DBIR (2024): SQL-инъекции остаются в тройке самых используемых техник для первоначального доступа
• HackerOne (2024): Средняя выплата за критическую SQLi — $5,000-$15,000
• Go-специфика: По данным Snyk, около 12% Go-приложений содержат хотя бы один случай конкатенации строк в SQL-запросах

Общие закономерности инцидентов

Анализ реальных случаев выявляет повторяющиеся паттерны:

1. Забытые эндпоинты — legacy-код, debug-страницы, тестовые API
2. Доверие к внутренним данным — данные из БД используются без параметризации (Second-Order)
3. ORM ложное чувство безопасности — raw-запросы внутри ORM остаются уязвимыми
4. Отсутствие мониторинга — атаки обнаруживаются через месяцы или годы
5. Минимальные привилегии не настроены — приложение подключается к БД с правами администратора

Извлечённые уроки для Go-разработчиков

1. Используйте prepared statements повсеместно — не только в «важных» обработчиках
2. Проводите аудит raw-запросов — grep -r "fmt.Sprintf.*SELECT\|fmt.Sprintf.*INSERT\|fmt.Sprintf.*UPDATE" .
3. Настройте govulncheck в CI — автоматическая проверка зависимостей
4. Внедрите логирование SQL-ошибок — это первый сигнал о попытке инъекции
5. Ограничьте привилегии БД — один пользователь для чтения, другой для записи