Повторное использование MySQL parser

Я работаю над SQL система обнаружения вторжений (IDS) и мне нужно проанализировать входящие SQL-запросы. Написание собственного парсера SQL-долгосрочная задача, и она никогда не будет точно отражать логику, используемую в собственном парсере. Я узнал, что MySQL имеет лексический анализатор с основным исходным файлом sql/sql_lex.cc и синтаксический анализатор, построенный с помощью bison из sql/sql_yacc.y. Я действительно заинтересован в повторном использовании этих надежных решений. Я создаю свои идентификаторы на C / C++, поэтому я ищу способ подключения MySQL парсер с моей системой обнаружения.

мне было интересно, можно ли повторно использовать MySQL parser (lexical+syntax analyzer), чтобы получить структуру SQL-запроса в некоторой логической форме, например, синтаксическое дерево. Возможно ли это? Есть ли какой-то связанный текст, учебники или проекты?

спасибо

6
lexical mysql parsing sql syntax

2 ответов

Я закончил первую версию моих идентификаторов как часть моего холостяцкого проекта. Он реализован как плагин для MySQL.

Я перечислю мои основные источники для понимания MySQL internals ниже. Затем я кратко описываю подход, который я использовал в своих идентификаторах.

тексты документации MySQL

  • Я нашел книги Эксперт MySQL by Чарльз Белл и Понимание MySQL Internals by Саша Пачев!--13--> (как писал user3822447), чтобы быть очень хорошей точкой входа для понимания внутренних компонентов MySQL.
  • MySQL 5.1 Разработка Плагинов by Эндрю Хатчингз И Сергей Голубчик также очень полезно.
  • на MySQL Internals Manual также содержит некоторую основную информацию, хорошую для начала.
  • после всего прочитанного я сделал som отладка (используя VS) и обнаружил, как структура дерева запросов выглядит так.

мое решение для IDS

исходный код моего решения можно найти в sourceforge. Я планирую документировать его немного больше в его wiki.

основной точкой входа является на audit_ids.cc. Плагин принимает дерево запросов, сгенерированное внутренним MySQL parser A делает упрощенную версию (для сохранения памяти). Затем он делает аномальное обнаружение - у него есть список известных структуры дерева запросов и сохраняет некоторую статистическую информацию о каждой параметризуемой части каждой структуры дерева запросов. Выходные данные записываются в специальный файл журнала в каталоге данных MySQL.

Я попытался сделать решение модульным и расширяемым. Начальная версия является своего рода демострацией, и производительность не оптимизирована, особенно в модуле хранения SQL.

MySQL тип плагина

Я определил 2 возможных подхода и использовал первый один.

  1. аудит плагин
    • тип обертки в моем плагине решения -аудит плагин.
    • я использовал этот тип плагинов, несмотря на то, что они используются для отчетов об операциях сервера (например, для регистрации запросов или ошибок).
    • Я выбрал этот тип плагина, потому что я узнал, что это единственный поддерживаемый плагин, который вызывается, когда дерево запросов после завершения (т. е. разбирается) и перед тем, как он освободится от памяти (для MySQL 5.6.17).
    • минус: вышеизложенное не полностью гарантировано в будущих версиях MySQL, но, на мой взгляд, это не должно измениться в ближайшем будущем.
    • преимущество: MySQL не нужно перекомпилировать. Достаточно построить и установить плагин.


  1. запрос-переписать плагин
    • существует также альтернативный подход, делающий это с использованием неродного типа плагина запрос-переписываем. Он provised API плагинов для изменения запроса, так и для чтения.
    • минус: для поддержки этого API плагина сервер MySQL должен быть перекомпилирован с API. Я думаю, что может стать частью дистрибутива MySQL production.
    • преимущество: тип плагина предназначен для чтения / перезаписи внутреннее дерево запросов.

Если есть какие-то Вопросы/Проблемы, связанные с этой темой, я мог бы ответить, не стесняйтесь спрашивать ;)

9

Я считаю, что это возможно. Попробуйте продвинутую книгу MySQL internals, такую как" Expert MySQL "Чарльза Белла или" понимание MySQL Internals " Саши Пачева. MySQL использует пользовательский ручной лексер и общий парсер, совместимый с Bison, с которым совместим их лексер.

помимо этого, вы можете найти более простое решение, чем разбор запроса, например:

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

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

1