SQL инъекции на практике: демонстрация уязвимостей

kirilljsx

Введение

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

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

Как устроена SQL инъекция

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

Рассмотрим типичный сценарий. Предположим, приложение выполняет такой запрос:

SELECT * FROM users WHERE id = ' + userInput + ''

Если пользователь введет 1 OR 1=1, запрос превратится в:

SELECT * FROM users WHERE id = 1 OR 1=1

Теперь запрос вернёт все записи из таблицы, потому что условие 1=1 всегда истинно. Это базовый пример, но на его основе строятся более сложные атаки.

Основные способы внедрения вредоносного кода:

Логические операторы: добавление OR, AND или NOT для изменения условий запроса
Комментарии: использование -- или /* */ для игнорирования остатка оригинального запроса
Union-запросы: объединение результатов с другим SELECT для извлечения данных из других таблиц
Слепые инъекции: когда нет прямого вывода результатов, но можно получить информацию через временные задержки или логические выводы
Множественные команды: выполнение нескольких SQL-операторов подряд (DROP, DELETE, INSERT)

Сценарии атак в тестовой среде

В контролируемой среде можно безопасно изучить, как хакер может манипулировать запросами. Первый сценарий — извлечение конфиденциальных данных. Предположим, в системе есть таблица с номерами карт. Если форма позволяет вводить ID пользователя, можно добавить условие:

SELECT * FROM orders WHERE user_id = 999 OR user_id = 1

Здесь 999 — несуществующий ID, но условие OR user_id = 1 позволит увидеть данные другого пользователя, включая номера карт.

Второй сценарий — изменение логики запроса. Злоумышленник может добавить в конец запроса комментарий и дополнительные условия:

SELECT * FROM products WHERE category = 'books' UNION SELECT * FROM admin_accounts --

Это позволит извлечь данные из таблицы администраторов, объединив результаты с исходным запросом.

Третий и наиболее опасный сценарий — удаление или изменение данных. Если приложение позволяет выполнять несколько команд, злоумышленник может добавить:

SELECT * FROM users; DROP TABLE users; --

При поддержке многострочных команд это удалит всю таблицу пользователей. Более осторожный вариант — изменение данных:

SELECT * FROM users WHERE id = 1; UPDATE users SET balance = 999999 WHERE id = 1; --

Основные типы атак для тестирования:

Извлечение данных: используются UNION-запросы, слепые инъекции, время выполнения для определения количества столбцов и типов данных
Модификация данных: UPDATE и INSERT для изменения информации в базе
Удаление информации: DROP для удаления таблиц или DELETE для очистки записей
Обход аутентификации: логические операторы в формах входа для получения доступа без пароля
Выполнение команд системы: в некоторых базах данных возможно выполнение команд ОС через SQL функции

Защита: параметризованные запросы

К счастью, существует проверенный способ предотвратить SQL инъекции — параметризованные запросы (prepared statements). Вместо того чтобы подставлять значения прямо в строку запроса, разработчик использует заполнители, а затем передаёт параметры отдельно.

Вот как это работает на практике. Вместо опасного кода:

query = "SELECT * FROM users WHERE email = '" + email + "'"

Мы пишем:

prepared_statement = "SELECT * FROM users WHERE email = ?"
result = execute(prepared_statement, [email])

База данных понимает структуру запроса ещё до получения параметров, поэтому любые спецсимволы в значении email будут обработаны как обычные данные, а не как SQL-код. Это принципиально отличается от конкатенации строк.

Многие разработчики думают, что можно использовать любой способ, если добавить фильтрацию входных данных. Это опасное заблуждение. Параметризованные запросы — это не просто удобно, это стандарт, к которому нужно привыкать с первого дня работы. Хранимые процедуры тоже помогают, но только если они внутренне используют параметры, а не конкатенацию.

Сравнение подходов защиты:

Метод	Безопасность	Удобство	Гибкость
Строковая конкатенация	Крайне низкая	Высокая	Высокая
Фильтрация входных данных	Средняя	Высокая	Средняя
Параметризованные запросы	Очень высокая	Высокая	Средняя
Хранимые процедуры	Высокая	Средняя	Низкая
ORM-фреймворки	Высокая	Высокая	Высокая

Реализация параметризованных запросов в разных языках:

Python (SQLite): cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
PHP (PDO): $stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?"); $stmt->execute([$user_id]);
JavaScript (Node.js): connection.query("SELECT * FROM users WHERE id = ?", [user_id], callback);
Java: PreparedStatement pstmt = conn.prepareStatement("SELECT * FROM users WHERE id = ?");

Тестирование в контролируемой среде

Прежде чем запускать приложение в продакшене, обязательно нужно провести тестирование на уязвимости. В тестовой среде можно смело экспериментировать, не опасаясь реальных последствий. Сначала выбирается изолированный сервер или виртуальная машина, затем на неё устанавливаются копии приложения и базы данных.

Тестирование начинается с самых простых инъекций. Берут формы ввода — поиск, фильтры, авторизацию — и пробуют добавлять ', ", OR 1=1, --. Если на странице что-то ломается или поведение меняется необычно, это сигнал к дальнейшему исследованию. Важно отметить в отчёте каждый найденный вход, где возможна инъекция.

Для серьёзного тестирования существуют автоматизированные инструменты, которые проверяют все параметры и логируют результаты. Однако ручное тестирование всё равно необходимо, потому что иногда уязвимость скрыта в неожиданном месте — например, в сортировке или фильтрации по столбцам базы данных.

Процесс тестирования на SQL инъекции:

Картирование входов: найти все формы, URL-параметры, заголовки, в которые пользователь может что-то ввести
Простые тесты: попробовать базовые инъекции (', OR 1=1) и наблюдать ошибки или изменения поведения
Определение типа БД: по сообщениям об ошибках понять, какая база данных используется (MySQL, PostgreSQL, MSSQL, Oracle)
Расширенное исследование: использовать UNION-запросы для определения количества столбцов и их типов
Извлечение данных: безопасно (в тестовой среде!) получить информацию о структуре БД и содержимом таблиц
Слепые инъекции: если прямого вывода нет, использовать логические условия и время ответа для получения информации

Чек-лист для тестирования:

Все ли формы используют параметризованные запросы?
Обработаны ли специальные символы SQL (одиночные кавычки, скобки, дефисы, точки с запятой)?
Логируются ли попытки внедрения кода?
Есть ли rate limiting на подозрительные запросы?
Разделены ли права доступа (сервисный аккаунт не имеет прав на DROP или DELETE)?
Используются ли ORM-фреймворки вместо raw SQL?

Больше чем просто код

Защита от SQL инъекций — это не только техника. Это культура разработки, где каждый понимает, что неправильная обработка данных может привести к краху системы и потере доверия пользователей. Параметризованные запросы должны быть рефлексом, а не исключением в коде. Когда весь колектив тестирует приложения на уязвимости в изолированной среде, появляется общее понимание рисков и ответственности.

Помимо SQL инъекций существуют другие типы атак — XSS, CSRF, путь обхода — которые требуют такого же внимания. Тестирование безопасности становится частью обычного рабочего процесса, а не чем-то экстраординарным. Каждая задача на код-ревью должна включать вопрос: как это может быть использовано неправильно, и защищены ли мы от этого? Вот этот образ мышления и отличает опытного разработчика от новичка.