Как защищают от SQL-инъекций различные вендоры СУБД

В 2025 году основным вектором атак стали SQL-инъекции, которые впервые за долгое время обогнали XSS по числу критических багов.

За более чем 30 лет своего существования инъекции эволюционировали, и, несмотря на борьбу с ними, продолжают своё существование, нанося значительный вред веб-приложениям, их владельцам и пользователям. Даже крупные организации с грамотным подходом и немалыми инвестициями в безопасность подвержены этим атакам. К примеру, в 2012 году произошла утечка 450 000 паролей пользователей Yahoo и тогда же были скомпрометированы более 6,5 миллионов хэшей паролей пользователей Linkedln, а в 2020 году из-за SQL-инъекций пострадала компания Freepik и данные входа её более чем 8 миллионов пользователей, и таких историй немало.

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

Внедрение опасного SQL-кода в запросы, которые направляются в базы данных. В итоге это позволяет злоумышленникам производить различные действия с данными, минуя встроенные механизмы обеспечения безопасности СУБД.

Виды SQL-инъекций

• IN-BAND — вид SQL-инъекции, когда нарушители используют один и тот же канал для получения и отправки запроса. Её целью является получение ответа в веб-браузере как можно скорее, если это возможно при проведении атаки вручную с помощью веб-браузера. Например, изменение в запросе имени пользователя таким образом, чтобы отображалось именно его имя. Пример запроса: «SELECT * FROM users WHERE user_id LIKE ‘current_user’».
• IN-BAND ERROR BASED (на основе ошибок) — вид внутриполостной SQL-атаки, при проведении которой нарушители используют сообщения ошибок сервера баз данных для разведки и определения структуры базы данных. Это один из самых распространённых видов SQL-атак. В качестве примера рассмотрим ситуацию, когда нарушитель пытается войти в систему, используя неверные данные: «имя пользователя: ‘ ИЛИ ‘ ‘а’ = ‘апароль: любой». База данных в этом случае вернёт ошибку, так как синтаксис оператора был неверен. Однако сообщение об ошибке принесёт злоумышленнику необходимую информацию о базе данных.
• IN-BAND UNION BASED — предоставляет возможность получения информации с помощью оператора UNION в целях объединения результатов двух или более запросов SELECT.
• BLIND, или «слепая SQL-инъекция», — вид атаки, при которой можно получить ответы из базы данных, лишь задавая простые вопросы и получая ответы в формате «да» или «нет» (словно «морской бой»). В результате атакующий анализирует информацию об ошибках и проверяет, насколько меняется реакция БД при использовании кода. Может быть двух видов: на основе булевых выражений и на основе времени.
• OUT OF BAND — злоумышленник отправляет SQL-запросы на сервер БД способом, отличным от обычного взаимодействия. В качестве примера — использование DNS- или HTTP-запросов. В данном случае ответ приложения не зависит от обычных факторов: возвращены ли данные, сколько времени занимает выполнение запроса, имеются ли проблемы с БД. Внеполосные события могут использоваться в сетевых взаимодействиях в целях произвольной активации событий, т. е. они могут активироваться для получения информации по одному биту в зависимости от установленного условия. Также возможна утечка данных через некоторые сетевые протоколы в ходе сетевого взаимодействия.

Реализация защиты от SQL-атак на уровне СУБД

SQL Firewall — это система защиты баз данных от SQL-инъекций и несанкционированного доступа. Она работает как фильтр запросов между приложением и базой данных, проверяя входящие запросы на наличие уязвимостей и подозрительных операций. Если рассматривать цепочку взаимодействия БД-СУБД-Пользователь, то SQL Firewall работает на участке между СУБД и базой данных.

В отсутствующем на отечественном рынке на данный момент Oracle Database для защиты от опасности заражения SQL-инъекцией реализовано комплексное решение, сочетающее в себе межсетевой экран для БД и систему аудита Oracle Audit Vault and Database Firewall. Устанавливаемые с помощью этого приложения политики безопасности помогают предупредить SQL-инъекции, обход приложения и другие возможные злонамеренные операции. Также здесь проводится аудит за действиями привилегированных пользователей и другими операциями в базе данных, требующими контроля.

Основные особенности:

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

SQL Firewall c остальными инструментами позволяет реализовать комплексный подход по обеспечению защиты баз данных от SQL-инъекций.

Рассмотрим современные реализации механизмов защиты от SQL-атак среди отечественных СУБД общего назначения.

Јatoba

В СУБД Jatoba защита от SQL-атак представляет собой SQL Firewall в виде расширения для СУБД, которое предназначено для выявления и предотвращения выполнения нетипичных SQL-запросов.

Главная задача данного компонента — защита БД от атак типа SQL-инъекции и иных непредвиденных запросов путём нормализации и проверки запросов перед исполнением.

Основные возможности расширения:

1. Фильтрация запросов:

• нормализует запросы,
• преобразует запросы в стандартные формы,
• проводит сравнение с известными шаблонами.

2. Режимы функционирования:

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

3. Настройка и мониторинг:

• конфигурируемость через параметр postgresql.conf;
• возможность вывода списка правил и статистики выполнения запросов;
• поддержка импорта правил, позволяющих переносить настройки между системами.

4. Безопасность:

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

Также в СУБД Jatoba реализована ролевая модель управления доступом к хранимой информации. Можно считать, что «пользователь» в обычном понимании — это роль, допускающая вход в систему, а «группа» — роль без права входа. Тем не менее никто не запрещает иметь «групповую роль» с правом входа. Также роль обладает атрибутами, определяющими её общие права (не связанные с правами доступа к объектам) и особенности. Настройка ролей и полномочий сделана весьма гибко, с тем чтобы в каждом конкретном случае администратор мог выбрать наиболее удобную схему управления. Можно сказать, что доступ роли к объекту определяется привилегиями.

Кроме того, в СУБД Jatoba реализован компонент контроля доступа JDV (Jatoba data valut) который предназначен для разграничения доступа пользователей к данным в таблицах.

Postgres Pro

В СУБД Postgres Pro защита от SQL-атак реализована двумя способами.

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

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

Стоит отметить, что на владельца таблицы такие политики обычно не действуют. Если политика для таблицы изначально не определена, то применяется политика запрета по умолчанию и никакие строки в этой таблице нельзя увидеть или модифицировать. На операции с таблицей, в целом, такие как TRUNCATE и REFERENCES, политика защиты строк не распространяется. Данные политики могут применяться к определённым командам и/или ролям. При необходимости политику можно определить как применяемую к командам ALL (всем), или SELECT, INSERT, UPDATE и DELETE. Кроме того, политику можно связать с несколькими ролями, и при этом действуют обычные правила членства и наследования.

2. Роли и привилегии. Используется концепция ролей для управления разрешениями доступа к информации в базе данных. Роль можно рассматривать: как пользователя БД или как группу пользователей, в зависимости от того, как эта роль настроена. Роли могут владеть объектами базы данных (таблицы, функции) и выдавать другим ролям разрешения на допуск к этим объектам, управляя процессом доступа. Кроме того, можно предоставить одной роли членство в другой роли и таким образом одна роль может использовать права других ролей.

Platform V Pangolin

В СУБД Pangolin для защиты от SQL-инъекций используется расширение plpgsql_check. Данное расширение довольно функционально и может выполнять следующие функции: проверка соответствия типов и полей таблиц, представлений и других объектов, используемых внутри SQL-кода процедур/функций, проверку передачи параметров в функцию/процедуру в соответствии с их объявленными типами, возможность проверки инструкций EXECUTE на наличие уязвимости SQL-инъекции. Можно сказать, что данное расширение выполняет проверку встроенных SQL-запросов, позволяет выявлять ошибки, которые обычно не обнаруживаются при создании процедур.

Также у pangolin есть возможность использовать отдельный пакет dbms_assert, который добавляет дополнительные проверки в целях защиты от SQL injection, например: квотирование строки, квотирование имени объекта sql, производит проверку существования в БД определённой схемы.

В СУБД Platform V Pangolin имеется система разграничения доступа, основанная на ролях, а также возможность назначать привилегии, которые устанавливаются парольными политиками в соответствии с ролевой моделью.

Tantor

Данная СУБД наследует преимущества, реализованные в PostgreSQL. В ней также реализована модель доступа на основе правил и политик.

Ред База данных

В Ред БД для защиты от SQL-инъекций используется базовый оператор GRANT, который предоставляет одну или несколько привилегий для объектов базы данных пользователям, ролям, хранимым процедурам, функциям, пакетам на доступ к объектам базы данных.

Заключение

Защита от SQL-атак при помощи политик защиты строк или привилегий реализована у всех рассмотренных СУБД.

На российском рынке только один вендор предлагает функционал защиты SQL Firewall, что позволяет более гибко настраивать политики безопасности с целью противодействия SQL-инъекциям, это СУБД Jatoba.

Авторы: Владимир Пучков, инженер-аналитик лаборатории развития и продвижения компетенций кибербезопасности Аналитического центра кибербезопасности компании «Газинформсервис»
Татьяна Буторина, старший методист лаборатории развития и продвижения компетенций кибербезопасности Аналитического центра кибербезопасности компании «Газинформсервис»