Статья SQL-инъекции: Анатомия атаки и искусство защиты через Prepared Statements

[Admin]

SQL-инъекция (SQLi) — это тип атаки, при котором злоумышленник внедряет вредоносный SQL-код в запрос к базе данных через входные данные приложения. Несмотря на то что этой уязвимости более 20 лет, она стабильно входит в топ-3 рейтинга критических угроз OWASP Top 10.

1. Как работает атака: Механика внедрения​

Представьте стандартную форму авторизации. Программа на сервере принимает логин и пароль и подставляет их в SQL-запрос:

-- Обычный запрос в коде сервера

"SELECT * FROM users WHERE username = '" + user_input + "' AND password = '" + pass_input + "'"

Сценарий взлома​

Хакер вместо обычного логина вводит в поле специальную конструкцию: ' OR '1'='1.


Что видит база данных:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '...'

Поскольку условие '1'='1' всегда истинно (True), база данных проигнорирует проверку пароля и вернет данные первого пользователя из таблицы (чаще всего это администратор). Так происходит обход авторизации.

Другие возможности SQLi:​

• UNION-based: Слияние таблиц для кражи данных из других разделов БД.
• Error-based: Вывод структуры базы через намеренные ошибки в ответах сервера.
• Blind SQLi (Слепая инъекция): Когда сервер не выводит ошибки, хакер задает вопросы («Начинается ли имя таблицы на букву А?») и анализирует время ответа сервера или изменения в контенте.

2. Современный стандарт защиты: Prepared Statements​

Самый эффективный способ борьбы с SQLi — Prepared Statements (Подготовленные выражения) или параметризованные запросы.

В чем их суть?​

В обычном (уязвимом) подходе данные пользователя смешиваются с кодом запроса. В Prepared Statements эти процессы разделены.

1. Шаблон запроса: Сначала сервер отправляет базе данных «скелет» запроса с плейсхолдерами (знаками вопроса или именованными параметрами).
2. Компиляция: База данных заранее компилирует этот шаблон, понимая, где в нем команды, а где должны быть данные.
3. Передача данных: Параметры (ввод пользователя) передаются отдельно.

Пример на языке PHP (PDO):

$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email'); // Шаблон
$stmt->execute(['email' => $user_input]); // Данные передаются отдельно

Почему это безопасно?​

Даже если пользователь введет ' OR '1'='1, база данных не воспримет это как часть команды. Для неё это будет просто одна длинная строка, которую нужно найти в колонке email. Поиск не даст результатов, и атака провалится.

3. Дополнительные уровни защиты (Defense in Depth)​

Хотя параметризация — это «золотой стандарт», опытные разработчики используют комплексный подход:

1. Принцип наименьших привилегий: Веб-приложение должно подключаться к БД под пользователем, который имеет доступ только к нужным таблицам (например, не может удалять таблицы или обращаться к системным логам).
2. Валидация данных: Если поле ожидает число (ID), нужно жестко проверять, что пришло именно число, еще до отправки в БД.
3. Использование ORM: Современные фреймворки (Django, Laravel, Hibernate) по умолчанию используют параметризацию, скрывая низкоуровневый SQL от разработчика.
4. WAF (Web Application Firewall): Внешние фильтры могут распознавать типичные SQL-сигнатуры во входящем трафике и блокировать их.

Заключение​

SQL-инъекции — это не проблема «умных хакеров», а проблема «небрежного кода». Использование Prepared Statements делает 99% подобных атак невозможными.