Что это за строка?

Строка OR EXTRACTVALUE(3791,CONCAT(0x7e,((SELECT (ELT(3791=3791,1)))),0x7e))-- - — это классический пример error-based SQL-инъекции (инъекции на основе ошибок) для СУБД MySQL. Такие конструкции используют для извлечения данных из базы через вывод сообщения об ошибке. Злоумышленник внедряет подобный код в уязвимый параметр веб-приложения, чтобы заставить сервер вернуть содержимое базы данных в тексте ошибки.

Подобные строки часто встречаются в логах веб-серверов, в отчётах сканеров уязвимостей и в системах обнаружения вторжений (IDS). Если вы увидели такую запись — это попытка атаки на ваш сайт или признак того, что кто-то тестирует его на проникновение.

Разбор по частям

Разберём выражение поэлементно, чтобы понять логику атакующего.

  • OR — логический оператор, который добавляется к исходному SQL-запросу. Если исходное условие ложно, OR с внедрённым выражением всё равно сделает запрос истинным (или вызовет ошибку).
  • EXTRACTVALUE(3791, ...) — функция MySQL для работы с XML. Она извлекает значение из XML-документа по XPath-выражению. Первый аргумент — XML-строка (в нашем случае просто число 3791), второй — путь XPath.
  • CONCAT(0x7e, ..., 0x7e) — конкатенация строк. 0x7e — это шестнадцатеричное представление символа ~ (тильда). Тильда используется как разделитель, чтобы облегчить чтение выводимых данных в сообщении об ошибке.
  • (SELECT (ELT(3791=3791,1))) — подзапрос, который возвращает результат функции ELT(). ELT(N, str1, str2, ...) возвращает N-ю строку из списка. Здесь условие 3791=3791 всегда истинно (равно 1), поэтому ELT(1, 1) вернёт строку 1. В реальной атаке вместо 1 подставляется SQL-запрос, извлекающий нужные данные (например, версию СУБД, имя базы, хеши паролей).
  • -- - — комментарий в MySQL. Всё, что идёт после -- (пробел обязателен), игнорируется парсером. Это позволяет отсечь остаток оригинального запроса.

В результате MySQL пытается выполнить EXTRACTVALUE с некорректным XPath-выражением, содержащим результат подзапроса, и выдаёт ошибку вида: XPATH syntax error: '~1~'. Именно в этом сообщении и «утекают» данные.

Как работает error-based SQL-инъекция через EXTRACTVALUE

Механизм основан на том, что СУБД MySQL при ошибке в XPath-выражении возвращает клиенту текст ошибки, включающий переданную строку. Атакующий конструирует подзапрос так, чтобы его результат попал в это сообщение.

Пошагово это выглядит так:

  1. Злоумышленник находит параметр, который подставляется в SQL-запрос без должной обработки (например, ?id=1).
  2. Вместо ожидаемого значения он передаёт строку с OR EXTRACTVALUE(...).
  3. Сервер формирует запрос, в котором выполняется функция EXTRACTVALUE с заведомо некорректным XPath, содержащим результат подзапроса.
  4. MySQL генерирует ошибку, и если приложение выводит её на страницу (или в ответ API), атакующий видит извлечённые данные.

В нашем примере подзапрос возвращает 1 — это тестовая проверка уязвимости. Если в ответе появляется XPATH syntax error: '~1~', значит, инъекция возможна. Далее вместо 1 подставляются реальные запросы: SELECT version(), SELECT database(), SELECT user() и т.д.

Почему EXTRACTVALUE и подобные функции опасны

Функции EXTRACTVALUE и UPDATEXML появились в MySQL для работы с XML. Однако они оказались удобны для атакующих, потому что:

  • возвращают подробные сообщения об ошибках с переданной строкой;
  • доступны во многих версиях MySQL (включая 5.7, 8.0);
  • не требуют специальных привилегий — достаточно прав на выполнение SELECT.

Аналогичными свойствами обладают и другие функции: GTID_SUBSET, JSON_KEYS, POLYGON и т.п. Все они используются в error-based инъекциях.

Последствия успешной атаки

Если злоумышленнику удаётся проэксплуатировать уязвимость, он может:

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

Даже если база не содержит критичных данных, компрометация может привести к репутационным и финансовым потерям.

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

Основной метод защиты — использование параметризованных запросов (prepared statements). Это означает, что данные передаются отдельно от SQL-кода и не могут изменить структуру запроса.

Дополнительные меры:

  • валидация и фильтрация всех входных данных (белые списки, приведение типов);
  • экранирование специальных символов с помощью функций СУБД (например, mysqli_real_escape_string);
  • использование ORM, которые автоматически применяют параметризацию;
  • ограничение прав пользователя базы данных (не использовать root для веб-приложения);
  • отключение вывода подробных ошибок на продакшене (display_errors = off);
  • регулярное обновление СУБД и фреймворков;
  • применение WAF (Web Application Firewall) для блокировки подозрительных запросов.
Важно: даже если сайт использует ORM, убедитесь, что в коде нет «сырых» SQL-запросов с конкатенацией пользовательских данных.

Что делать, если вы нашли такую строку в логах

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

  1. Проверить код приложения на наличие уязвимостей (аудит, сканеры).
  2. Просмотреть другие логи на предмет успешных инъекций.
  3. Убедиться, что на продакшене отключён вывод ошибок.
  4. Обновить СУБД и CMS до актуальных версий.
  5. Настроить WAF или правила IDS для блокировки подобных запросов.

Помните: error-based SQL-инъекция — лишь один из многих методов атак. Комплексный подход к безопасности поможет защитить ваш ресурс.

Заключение

Строка OR EXTRACTVALUE(3791,CONCAT(0x7e,((SELECT (ELT(3791=3791,1)))),0x7e))-- - — это типичный пример error-based SQL-инъекции, использующей функцию EXTRACTVALUE для извлечения данных через сообщения об ошибках MySQL. Понимание принципов работы таких атак помогает разработчикам и администраторам своевременно выявлять и устранять уязвимости. Главная защита — параметризованные запросы и внимательное отношение к безопасности на всех этапах разработки.

Источники