Что такое SQL-иньекция?

Что такое SQL-инъекция?

SQL-инъекция (SQL Injection, SQLi) — это один из самых опасных и распространённых методов атаки на веб-приложения, основанный на внедрении злоумышленником произвольного SQL-кода во входные данные приложения. Целью атаки является манипуляция исходными SQL-запросами приложения для выполнения неавторизованных операций с базой данных.

Причины уязвимости:

• Некорректная или отсутствующая валидация пользовательского ввода.
• Динамическое построение SQL-запросов путём конкатенации строк с данными от пользователя.
• Неиспользование механизмов параметризованных запросов (prepared statements) или недостаточное экранирование спецсимволов.

Типовые примеры атаки

Представьте форму входа, где бэкенд формирует запрос таким образом:

-- Оригинальный запрос приложения
SELECT * FROM users WHERE login = '$login' AND password = '$password';

Если злоумышленник введёт в поле login значение admin'--, а пароль оставит пустым, итоговый запрос примет вид:

SELECT * FROM users WHERE login = 'admin'--' AND password = '';

Символы -- в SQL обозначают начало комментария. В результате условие проверки пароля игнорируется, и атакующий получает доступ к учётной записи администратора.

Более опасные инъекции могут приводить к чтению, изменению или удалению любых данных, а также к выполнению административных команд на сервере СУБД.

-- Пример инъекции, раскрывающей структуру БД (UNION-атака)
' UNION SELECT table_name, column_name FROM information_schema.columns WHERE table_schema = database() --

Последствия успешной SQL-инъекции

• Утечка конфиденциальных данных: паролей, персональной информации, платёжных данных.
• Обход аутентификации и авторизации.
• Модификация или уничтожение данных в БД (DROP, DELETE, UPDATE).
• Выполнение произвольных команд на сервере БД (например, через xp_cmdshell в MS SQL Server).
• Компрометация всего сервера при определённых условиях.

Методы защиты и предотвращения

Основной и самый эффективный принцип — разделение кода и данных.

1. Использование параметризованных запросов (Prepared Statements).

    Это самый надёжный способ. Плейсхолдеры в запросе (например, `?` или `@param`) заранее компилируются СУБД, а пользовательские данные передаются отдельно, интерпретируясь исключительно как данные, а не как часть команд.

```java
// Пример на Java с использованием PreparedStatement
String sql = "SELECT * FROM users WHERE login = ? AND password = ?";
PreparedStatement stmt = connection.prepareStatement(sql);
stmt.setString(1, userLogin); // Данные безопасно подставляются
stmt.setString(2, userPassword);
ResultSet rs = stmt.executeQuery();
```

2. Строгая валидация и санитизация (очистка) входных данных.

    *   Проверка на тип данных (число, строка).
    *   Использование **белых списков (whitelisting)** разрешённых значений или символов.
    *   Экранирование специальных символов с помощью функций типа `mysqli_real_escape_string()` (но это менее надёжно, чем prepared statements).

1. Принцип наименьших привилегий (Principle of Least Privilege).

    Учётная запись приложения для работы с БД должна иметь строго минимально необходимые права (обычно только SELECT, INSERT, UPDATE для конкретных таблиц). Никаких прав на DROP, экспорт данных или выполнение системных команд.

1. Регулярное тестирование на уязвимости.

    *   **Ручное тестирование**: методом "чёрного ящика" с использованием различных векторов атак (`'`, `"`, `;`, `UNION`, `SLEEP()`, `OR 1=1`).
    *   **Автоматизированное сканирование**: с помощью инструментов вроде **SQLMap**, **Burp Suite Scanner**, **OWASP ZAP**.
    *   **Статический анализ кода (SAST)** и **динамический анализ (DAST)** для выявления потенциально опасных паттернов в коде.

1. Логирование и мониторинг.

    Ведение журналов всех необычных или подозрительных запросов к БД для оперативного обнаружения попыток атак.

Заключение для QA-инженера

Для QA-специалиста понимание SQL-инъекций критически важно. Это не просто теоретическое знание, а основа для:

• Составления исчерпывающих тест-кейсов на безопасность.
• Осмысленного ручного пентеста входных полей (форм поиска, авторизации, фильтров).
• Анализа отчётов автоматических сканеров безопасности.
• Общения с разработчиками на одном языке при обсуждении уязвимостей и способов их устранения.

Проверка на SQLi должна быть обязательным пунктом в чек-листе тестирования любого функционала, взаимодействующего с базой данных через пользовательский ввод.