Руслан Рахметов, Security Vision
Одной из основных целей современных кибератак являются различные веб-приложения - они доступны для широкого круга пользователей, обрабатывают интересующую злоумышленников информацию (например, персональные и платежные данные), а также подвержены различным уязвимостям. Одним из наиболее популярных векторов атак являются инъекции - веб-приложение уязвимо для атак методом инъекции в случае, когда вводимые пользователями данные не проверяются на безопасность. Сегодня поговорим об SQL-инъекциях - одном из старейших, но до сих пор популярном методе атак на веб-приложения.
Покажем на простых примерах, что такое SQL-инъекция (может также обозначаться как SQL injection, сокращенно SQLi). Для этого нужно представлять, как взаимодействуют между собой веб-сайты и базы данных, которые хранят информацию для сайтов, включая сведения о продаваемых товарах, логины и пароли пользователей, данные банковских карт и прочую ценную информацию. В простейшем случае, пользователь вводит какой-либо запрос в определенном поле на сайте - например, выполняя поиск доступных для заказа шляп в интернет-магазине. Веб-сайт формирует HTTP GET-запрос, который отображается в адресной строке браузера:
hxxps://supershop[.]com/products?category=hats
Веб-запрос от пользователя в интерфейсе сайта преобразуется в запрос для базы данных - в нём происходит поиск товаров в категории «шляпы» с автоматическим добавлением условия, что шляпы должны быть в наличии ("instock = 1"):
SELECT * FROM products WHERE category = 'hats' AND instock = 1
Запрос формируется на языке SQL (Structured Query Language, язык структурированных запросов), который позволяет управлять данными в реляционных базах данных с помощью СУБД, таких как MS SQL Server, PostgreSQL, OracleDB, MySQL, MariaDB, SQLite. Для управления данными, размещенными в столбцах и строках в таблице базы данных, применяются SQL-команды (например, SELECT, INSERT INTO, UPDATE, DELETE), а для управления самими таблицами используются другие SQL-команды (например, ALTER TABLE, DROP TABLE).
Исследователи безопасности поняли, что если логика веб-приложения или защитных решений не отфильтровывает ввод специальных символов от пользователя, то можно сформировать произвольный запрос, введя в адресной строке браузера следующее:
hxxps://supershop[.]com/products?category=hats' OR 1=1--
В этом запросе мы поставили спецсимвол - одинарную кавычку (разделитель для обозначения последовательности символов в языке SQL), логическое выражение "OR 1=1" («ИЛИ 1=1», что будет всегда верно) и два дефиса. Первый символ (одинарная кавычка) используется для закрытия исходного запроса, чтобы веб-сайт не начал искать категорию товаров, соответствующую текстовой строке "hats OR 1=1--". Логическое выражение "OR 1=1" используется для того, чтобы вывести весь список продуктов на экран - не только шляпы, но и вообще всё, что есть в магазине. Два дефиса ("--") используются в SQL как символы комментирования - это значит, что будут проигнорированы все дальнейшие части SQL-запроса ("AND instock = 1") для того, чтобы запрос вернул не только товары в наличии.
В результате, веб-запрос преобразуется в следующее SQL-выражение:
SELECT * FROM products WHERE category = 'hats' OR 1=1--' AND instock = 1
Этот SQL-запрос аналогичен запросу "SELECT * FROM products", результатом выполнения которого станет отображение всего списка продуктов, что атакующие могут использовать для просмотра скрытых товаров или создания излишней нагрузки на сайт.
Более серьезные последствия наступят в случае, если атакующие залогинятся под учетной записью администратора, пользуясь той же уязвимостью веб-сайта к SQL-инъекциям. Даже если логин и пароль администратора неизвестны, атакующие могут попробовать ввести в поле ввода логина следующее выражение (оставив пароль пустым):
' OR 1=1--
Таким образом, будет сформирован веб-запрос вида:
hxxps://supershop[.]com/users?login=' OR 1=1--
В этом случае СУБД обработает SQL-запрос вида:
SELECT id FROM users WHERE login = ' ' OR 1=1--' AND password = ' '
В данном случае в условии после login идёт пустое значение, окруженное одинарными кавычками, и логическое выражение "OR 1=1" (оно всегда возвращает верный результат, поэтому условие выполнится даже при пустом логине), а оставшаяся часть запроса с проверкой пароля закомментирована. Таким образом, атакующие смогут зайти на сайт под учетной записью первого пользователя из таблицы "users" - с большой долей вероятности это будет администратор. Однако, поскольку сформированный SQL-запрос возвращает все значения "id" из таблицы "users", это может идти вразрез с логикой веб-приложения, которое может ожидать только одно значение. Кроме того, конструкция "OR 1=1" при использовании операторов UPDATE или DELETE может привести к нежелательным для атакующего последствиям, включая удаление данных в таблице.
Приведенные примеры весьма просты, а в реальных атаках используются не только использованные выше GET-запросы, но и запросы методом POST, и SQL-инъекции с помощью модификации контролируемых пользователем cookie-файлов и HTTP-заголовков. Кроме того, инъекции опасны не только для реляционных БД, но и для нереляционных (NoSQL) - для реализации атаки потребуется чуть более сложный синтаксис, учитывающий специфику используемой СУБД (например, MongoDB, Redis, Apache Cassandra, Oracle NoSQL).
Последствиями атаки с использованием SQL-инъекции могут стать:
1) Компрометация учетных данных, имперсонация других пользователей и администраторов веб-приложения и базы данных;
2) Получение, изменение, удаление любых данных, хранящихся в БД;
3) Управление всей СУБД, с возможностью удаления таблиц и имеющихся БД;
4) Реализация отказа в обслуживании веб-приложения или БД за счет запуска «тяжелых» запросов;
5) Получение доступа к ОС, на которой установлена СУБД, с исполнением команд ОС, управлением сервисами, доступом к реестру и файловой системе от имени учетной записи, из-под которой запущена СУБД.
Открытый проект безопасности веб-приложений OWASP (Open Web Application Security Project) опубликовал первую версию своего списка из 10 наиболее распространенных типов веб-уязвимостей и ошибок конфигурирования веб-приложений в 2003 году, и в нём на 6 месте фигурировала атака методом инъекций, включая SQL-инъекции. Однако, первые предположения о возможности использования уязвимостей приложений к инъекциям, т.е. внедрению небезопасных пользовательских данных, появились еще в 1998 году, когда была опубликована статья с описанием возможности внедрения небезопасных конструкций в связке актуальных на тот момент веб-сервера MS IIS 4.0 и СУБД MS SQL Server 6.5. Уже в 2002 году SQL-инъекция использовалась в демонстрационной атаке на фэшн-ритейлера «Guess» - исследователи смогли получить доступ к данным банковских карт более 200 тысяч пользователей веб-сайта и сообщили об этом компании «Guess», которая устранила уязвимость, но тем не менее в 2003 году выплатила штраф за нарушение правил защиты данных покупателей.
В дальнейшем атакующие совершенствовали свои знания о методах реализации SQL-инъекций, появилась классификация типов подобных атак, а их популярность только росла. Так, атаки методом инъекций попали на первое место в списке OWASP Top-10 в 2010 году и удерживали пальму первенства вплоть до 2021 года, когда в перечне OWASP Top-10 они переместились на 3 место и были объединены с XSS-уязвимостями. Причины появления SQL-инъекций описаны на странице с описанием CWE-89: Improper Neutralization of Special Elements used in an SQL Command («Некорректная нейтрализация специальных символов, использующихся в SQL-команде»), а методы атак с использованием SQL-инъекций описаны на странице с описанием CAPEC-66: SQL Injection.
Атаки с использованием SQL injection активно проводятся и сейчас, несмотря на их известность в течение более 25 лет. В каталоге CISA KEV (Known Exploited Vulnerabilities, известные эксплуатируемые уязвимости) содержатся данные об использовании SQLi-уязвимостей в масштабных кибератаках, например:
· CVE-2025-25257 (уязвимость к SQL-инъекции межсетевого экрана уровня приложений Fortinet FortiWeb);
· CVE-2025-25181 (уязвимость к SQL-инъекции SaaS-платформы для логистики Advantive VeraCore);
· CVE-2024-9465 (уязвимость к SQL-инъекции инструмента для миграции данных Palo Alto Networks Expedition);
· CVE-2024-29824 (уязвимость к SQL-инъекции решения для управления конечными точками Ivanti Endpoint Manager);
· CVE-2023-34362 (уязвимость к SQL-инъекции популярного корпоративного веб-приложения MOVEit Transfer, в результате эксплуатации которой были взломаны более 2700 компаний по всему миру).
В настоящий момент принята следующая классификация SQL-инъекций по методам их реализации:
1. Классические SQL-инъекции (также называются "in-band SQL injection", т.е. внутриполосные SQL-инъекции): в них уязвимое веб-приложение возвращает результата инъекции атакующему через один и тот же канал коммуникации - например, если SQLi-атака выполняется через браузер, то и результат атаки будет отображен на веб-странице. Приведенные выше примеры, в которых атакующий логинится на сайт без пароля или получает список всех продуктов, являются примерами классических SQL-инъекций.
К классическим SQL-инъекциям относятся также следующие подтипы:
1.2. SQLi-атаки на основе ошибок ("Error-based SQL injection"): в результате вредоносного запроса СУБД возвращает атакующему ошибки, в которых могут быть указаны тип и версия СУБД и сведения о структуре БД - именно с такого типа атак могут начинаться дальнейшие поиски SQLi-уязвимостей. Классическим «учебным» способом проверить веб-приложение на наличие SQLi-уязвимости и просмотреть сообщение об ошибке в СУБД будет ввод одинарной кавычки (') в форме ввода на сайте.
1.2. SQLi-атаки с применением оператора UNION ("Union-based SQL injection"): в этой атаке результаты исходного запроса к БД объединяются с результатами запроса, вводимого атакующим с помощью выражения UNION SELECT (при этом создаваемый атакующим запрос должен возвращать то же число столбцов, что и исходный запрос, а типы данных в столбцах должны совпадать).
2. Слепые SQL-инъекции ("Blind SQL injection", также называются "Inferential SQL injection", т.е. инференциальные или выводные SQL-инъекции): атакующий не получает очевидного ответа от взламываемого приложения, но на основе его поведения делает заключение о структуре БД и архитектуре веб-приложения.
Слепые SQL-инъекции разделяются на подтипы:
2.1. Логические слепые SQL-инъекции ("Boolean-based blind SQL injection", также называются "Content-based blind SQL injection", т.е. слепые SQL-инъекции, основанные на контенте): атакующие объединяют легитимные запросы с логическими условиями (например, вида "AND 1=1" или "AND 1=0") и пытаются выяснить структуру или прочитать содержимое БД, ориентируясь на косвенные признаки и изменяющиеся ответы веб-приложения на такие запросы.
2.2. ВременнЫе слепые SQL-инъекции ("Time-based blind SQL"): атакующие объединяют легитимные запросы с SQL-запросами, которые выполняются с задержкой, и на основе анализа изменившегося поведения веб-приложения делают выводы о структуре или содержимом БД.
3. Внеполосные SQL-инъекции ("Out-of-band SQL injection"): при таких атаках злоумышленники получают результаты своего запроса в другом канале коммуникации - например, результаты вредоносного веб-запроса приходят в виде содержимого HTTP или DNS-запроса к серверу атакующих или записываются в сетевую папку, контролируемую хакером.
4. Стековые запросы ("Stacked Queries", также называются "Piggy-backed Queries", т.е. незаметно присоединенные запросы): атакующий добавляет вредоносный запрос к легитимному, используя разделитель запросов (;) в поле ввода данных (однако не все СУБД поддерживают выполнение стековых запросов).
5. SQL-инъекции второго порядка ("Second Order SQL Injection", также называются "Stored SQL injection", т.е. хранимые SQL-инъекции): атакующий предварительно сохраняет вредоносные конструкции в БД атакуемого ресурса и дальше вызывает их в других запросах.
6. Атаки с использованием уязвимых хранимых процедур ("Stored Procedure Attack"): в случае, когда хранимая процедура обрабатывает данные пользовательского ввода, она может быть уязвима для SQL-инъекций.
7. ORM-инъекции ("Object Relational Mapping Injection"): для обеспечения безопасного доступа веб-приложения к СУБД могут использоваться промежуточные звенья - например, за счет использования технологии ORM (Object–Relational Mapping, объектно-реляционное преобразование), которая выступает посредником между приложением и СУБД. В этой технологии, несмотря на цели её применения, также могут быть обнаружены уязвимости и реализованы инъекции, описанные в том числе в CAPEC (CAPEC-109: Object Relational Mapping Injection).
8. Атаки с использованием расширенных хранимых процедур, встроенных в MS SQL Server: при неправильной настройке атакующие могут получить возможность запускать команды ОС от имени учетной записи, из-под которой запущена СУБД, а также управлять сервисами, получать доступ к реестру, файловой системе, сети. Могут использоваться такие встроенные в MS SQL Server хранимые процедуры, как xp_cmdshell, xp_regdeletekey, xp_servicecontrol, xp_availablemedia, xp_ntsec_enumdomains и другие. Кроме того, можно получить NTLM-хэш от пароля учетной записи, из-под которой запущен MS SQL Server - например, за счет обращения к сетевой папке с помощью расширенных хранимых процедур «xp_fileexist» и «xp_dirtree» или за счет использования инструкции BULK INSERT.
Для автоматизации SQLi-атак злоумышленники применяют различные инструменты, самыми известными из которых являются sqlmap, sqlninja, SQLDump. Методы защиты от SQL-инъекций также известны:
1) санитизизация (очистка) вводимых пользователями данных, использование «белых списков» для вводимых пользователями данных (например, выбор значения из списка, а не ввод вручную), фильтрация данных по ожидаемым типам (например, только натуральные числа, только буквенно-цифровые символы);
2) использование параметризованных запросов;
3) написание безопасных хранимых процедур;
4) реализация принципа наименьших привилегий - предоставление минимально необходимых прав доступа учетным записям, из-под которых запускаются СУБД, работают веб-приложения на сервере, выполняется доступ веб-приложения к СУБД. Необходимо ограничивать права доступа к отдельным таблицам, по возможности предоставлять доступ только на чтение данных, создавать view и предоставлять доступ только к ним, предоставлять доступ только к необходимым хранимым процедурам, а также создавать отдельные аккаунты с гранулированными привилегиями для каждого веб-приложения, которому требуется доступ к СУБД;
5) использование техник и фреймворков со встроенными механизмами защиты от SQL-инъекций;
6) защищенная настройка СУБД в соответствии с рекомендациями и лучшими практиками;
7) реализация концепции Zero Trust, включая микросегментацию сети, условный доступ, категорирование данных;
8) использование платформ защиты базы данных (Database Security) - решений для контроля обработки структурированных данных, обрабатывающихся в базах данных, обладающих функционалом настройки и применения политик обработки данных, контроля и ограничения прав доступа к ним, журналирования обработки данных;
9) использование межсетевых экранов уровня приложений (WAF, Web Application Firewall) - программных или аппаратных решений для обеспечения сетевой безопасности, предназначенных для обеспечения безопасности веб-приложений с блокировкой подозрительных действий (включая попытки SQL-инъекций) и установкой виртуальных патчей;
10) использование инструментов для статического анализа кода (SAST, Static Application Security Testing), динамического анализа приложений (DAST, Dynamic Application Security Testing), интерактивного анализа приложений (IAST, Interactive Application Security Testing), поведенческого анализа приложений (BAST, Behavioral Application Security Testing).
.jpg)
