SQL-инъекция — одна из самых опасных веб-уязвимостей. Недавно к нам обратился клиент — интернет-магазин на PHP 7.4 с MySQL 5.7, потерявший 50 000 записей клиентов из-за одной неэкранированной кавычки. Ущерб от такой утечки может достигать 3–5 млн рублей с учётом штрафов и репутационных потерь. Восстановление после атаки обходится в 3–5 раз дороже, чем профилактика. Ваш сайт может быть следующим. Наша команда предлагает комплексное решение по защите от SQL-инъекций, имея 10+ лет опыта и более 200 успешных проектов.
Реальный кейс: как мы спасли интернет-магазин от SQL-инъекции
Клиент обратился после инцидента — злоумышленник через уязвимую форму поиска выгрузил всю таблицу customers. Причина — конкатенация ввода напрямую в SQL-запрос: $sql = "SELECT * FROM products WHERE name LIKE '%{$search}%'";. Таких мест мы нашли 12 в legacy-коде. Наша команда за 3 дня аудита выявила все точки входа, затем за 4 дня заменила все запросы на параметризованные через PDO, настроила WAF на основе ModSecurity с правилами OWASP CRS и ограничила права пользователя БД на уровне MySQL. После повторного сканирования уязвимости не обнаружены. Клиент также получил мониторинг логов в реальном времени.
Почему SQL-инъекции до сих пор опасны?
По данным OWASP Top 10, атаки внедрения кода входят в тройку самых критичных уязвимостей. Причина — неиспользование подготовленных запросов в legacy-коде. Недавние исследования показали, что более 60% веб-приложений имеют хотя бы одну SQL-уязвимость. Параметризованные запросы предотвращают 99,9% атак, что в 50 раз надёжнее одной только валидации ввода (которая даёт лишь 70–80%).
Как защитить сайт от SQL-инъекций?
Мы применяем комплексный подход, комбинируя несколько уровней защиты:
| Метод | Надёжность | Сложность внедрения |
|---|---|---|
| Подготовленные запросы | Высокая (99,9%) | Средняя (требует рефакторинга) |
| Валидация ввода | Средняя (70–80%) | Низкая (дополнительные проверки) |
| WAF (Web Application Firewall) | Дополнительная защита | Низкая (настройка правил) |
| Минимальные привилегии | Высокая | Низкая (настройка прав БД) |
| Экранирование (устарело) | Низкая (50–60%) | Средняя |
Лучший результат даёт комбинация подготовленных запросов и принципа минимальных привилегий. Подготовленные запросы блокируют практически все инъекции, а ограничение прав пользователя БД минимизирует ущерб при успешной атаке.
Примеры параметризованных запросов в разных языках
| Язык / Библиотека | Пример кода |
|---|---|
| PHP (PDO) | $stmt = $pdo->prepare('SELECT * FROM users WHERE email = ?'); $stmt->execute([$email]); |
| Python (psycopg2) | cur.execute('SELECT * FROM users WHERE email = %s', (email,)) |
| Node.js (pg) | client.query('SELECT * FROM users WHERE email = $1', [email]) |
| Java (JDBC) | PreparedStatement stmt = conn.prepareStatement('SELECT * FROM users WHERE email = ?'); stmt.setString(1, email); |
| Laravel Eloquent | User::where('email', $email)->get(); (без raw) |
Во всех примерах данные передаются отдельно от SQL-кода, что делает инъекцию невозможной.
Как проверить свой код на уязвимости?
Начните с поиска мест, где пользовательский ввод напрямую конкатенируется в SQL-запросы. Используйте grep для поиска $_GET, $_POST, Request::input() и последующей конкатенации. Особое внимание уделите raw-запросам в ORM, таким как whereRaw или DB::raw. Для автоматизации можно применять статические анализаторы (Phan, Psalm) с правилами безопасности.
Подготовленные запросы: стандарт защиты
Параметризованные запросы — единственный безопасный путь. Они отделяют код от данных. Пример на PHP:
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ? AND active = ?'); $stmt->execute([$email, 1]); $user = $stmt->fetch(); В современных фреймворках ORM (Eloquent, Sequelize) делают это автоматически. Но осторожно: некоторые методы принимают сырые фрагменты.
Опасные места в ORM
// Laravel — ОПАСНО User::whereRaw("name = '$name'")->get(); // БЕЗОПАСНО User::whereRaw('name = ?', [$name])->get(); Всегда используйте связывание параметров. Это снижает риск на 95%.
Дополнительные слои защиты
WAF (ModSecurity, Cloudflare) перехватывает инъекции на уровне HTTP. Принцип минимальных привилегий ограничивает права пользователя БД — даже при успешной атаке злоумышленник не сможет удалить таблицы.
Процесс работы
- Анализ кода — ищем конкатенацию и whereRaw через grep.
- Исправление — заменяем на prepared statements или ORM.
- Настройка WAF — добавляем правила для типовых атак.
- Проверка — сканируем sqlmap и пентестами.
- Мониторинг — настраиваем логи и алерты.
Что входит в работу
- Полный аудит исходного кода с отчётом.
- Исправление всех найденных уязвимостей.
- Настройка WAF и мониторинга.
- Рекомендации по безопасной разработке.
- Гарантия на исправления — 6 месяцев.
Сроки и результаты
- Аудит: 1–3 дня.
- Исправление: 2–7 дней.
- WAF + мониторинг: 1 день.
Экономия бюджета по сравнению с устранением последствий — до 80%. После нашей работы риск SQL-инъекций снижается на 95%. Хотите проверить свой сайт? Свяжитесь с нами — мы бесплатно оценим один endpoint. Закажите аудит и получите консультацию инженера.