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

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

Последствия могут быть разными: от обхода авторизации до чтения, изменения или удаления данных из базы.

Разбор реальных атак

Атака №1: time-based blind SQL injection

ubaTaeCJO"XOR(if(now()=sysdate(),sleep(15),0))XOR"Z

Это пример слепой SQL-инъекции, основанной на времени ответа сервера. В такой атаке злоумышленник не получает данные напрямую, а проверяет уязвимость по задержке ответа.

• XOR(... )XOR — попытка обойти простые фильтры и сигнатуры.
• if(now()=sysdate(),sleep(15),0) — условие, которое в MySQL обычно истинно.
• sleep(15) — задержка ответа на 15 секунд.

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

Атака №2: boolean-based SQL injection

-1' OR 2+440-440-1=0+0+0+1 or 'ffWtglzR'='

Это уже классическая логическая SQL-инъекция. Её задача — изменить условие запроса так, чтобы оно всегда становилось истинным.

• -1' — попытка закрыть строковое значение в SQL.
• OR 2+440-440-1=0+0+0+1 — замаскированное условие вида 1=1.
• or 'ffWtglzR'=' — хвост запроса, который помогает встроиться в исходную конструкцию.

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

Атака №3: рандомизированный вариант той же инъекции

-1' OR 2+918-918-1=0+0+0+1 or 'j0b66uWv'='

По сути это та же атака, что и предыдущая, но с другими числами и случайной строкой. Это делается для обхода примитивных фильтров, которые ищут только конкретные шаблоны.

Если в одном письме или в логах видно несколько похожих вариаций с меняющимися числами и строками, это сильный признак автоматизированного сканирования, например с помощью sqlmap.

Как понять, что это именно SQL-инъекция

Есть несколько характерных признаков, по которым такие запросы можно распознать даже без глубокого анализа:

• Наличие SQL-операторов: SELECT, UNION, OR, AND, DROP, INSERT.
• Наличие SQL-функций: sleep(), benchmark(), now(), sysdate().
• Кавычки и попытки разорвать строку: ', ".
• Комментарии SQL: --, #, /* */.
• Логические конструкции: OR 1=1, AND 1=2.
• Неестественная арифметика в полях формы: 2+440-440-1=1.
• Обфускация: XOR, hex-значения, случайные строки.

Если такие строки приходят в обычные текстовые поля вроде имени, названия или комментария, это практически всегда попытка атаки, а не ошибка пользователя.

Что смотреть в логах

Если подобные строки пришли в письме от формы, нужно сразу проверить access-логи веб-сервера и, при наличии, журналы безопасности Битрикса.

Особенно важно искать:

• Запросы с sleep, xor, union, select, or 1=1.
• URL-кодированные кавычки: %27, %22.
• Повторяющиеся запросы с одного IP с разными вариациями payload.
• Коды ответа 200 на подозрительные запросы.
• Необычно долгие ответы сервера, особенно около 10–15 секунд.
• Ошибки 500, которые могут указывать на поломку SQL-запроса.

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

Как защититься от SQL-инъекций

1. Использовать prepared statements

Это главный и обязательный способ защиты. Запрос и пользовательские данные должны передаваться отдельно, а не склеиваться в одну строку.

$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");
$stmt->execute([
    'email' => $_POST['email']
]);

В таком случае даже вредоносный ввод будет интерпретирован как строка, а не как часть SQL-кода.

2. Включить и настроить проактивную защиту Битрикс

В 1С-Битрикс есть встроенный модуль проактивной защиты, который может блокировать SQL-инъекции, XSS и другие типовые атаки. Если он доступен в редакции проекта, его нужно включить и перевести в режим блокировки, а также активировать журнал вторжений.

3. Ограничить права пользователя базы данных

Приложение не должно подключаться к БД под пользователем с административными правами. Для сайта обычно достаточно SELECT, INSERT, UPDATE, DELETE. Права вроде DROP, ALTER, GRANT лучше не выдавать.

4. Проверять и валидировать ввод

Валидация не заменяет параметризацию, но служит дополнительным слоем защиты. Если поле должно содержать имя, не нужно принимать туда длинные строки с управляющими символами, SQL-операторами и бессмысленной арифметикой.

5. Использовать ORM или безопасные абстракции

ORM снижает риск ошибок, потому что запросы чаще строятся безопасно и параметризованно. Это не абсолютная защита, но хороший способ уменьшить число ручных ошибок в коде.

6. Подключить WAF

Внешний WAF или встроенный фильтр на уровне веб-сервера помогает отсекать массовые автоматические атаки. Это полезный дополнительный слой, но не замена безопасной разработки.

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

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

Какой вывод можно сделать по этим примерам

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

Особенно важно, что пейлоады варьируются: меняются числа, случайные строки и структура. Это типично для автоматических инструментов, которые перебирают техники обхода фильтров.

Для владельца сайта главный практический вывод такой: если подобное пришло в письме от формы, нужно не только удалить сообщение как спам, но и проверить логи, включить защиту Битрикса, убедиться в использовании prepared statements и пересмотреть права пользователя БД.

Краткий чек-лист

• Проверить access-логи и журнал вторжений Битрикса.
• Найти все запросы с sleep, xor, union, or 1=1.
• Проверить, были ли ответы 200 и задержки выполнения.
• Убедиться, что в коде используются prepared statements.
• Включить проактивную защиту Битрикса и блокировку IP.
• Ограничить права пользователя базы данных.
• Обновить Битрикс и все модули, работающие с формами.

Само наличие таких строк — уже сигнал, что сайт сканируют. А значит, вопрос не в том, бывает ли такое, а в том, насколько быстро и правильно вы на это отреагируете.