SQL-инъекции

SQL-инъекция (англ. SQL injection) — это один из наиболее распространённых видов атак на веб-приложения, при котором злоумышленник внедряет произвольный SQL-код в запросы к базе данных, формируемые приложением. Атака возможна, когда входные данные от пользователя (например, из полей форм, параметров URL или cookie) некорректно обрабатываются и напрямую конкатенируются в строку SQL-запроса без предварительной санитизации или экранирования. В результате атакующий может читать, изменять или удалять данные в базе, а в некоторых случаях — выполнять команды на уровне сервера баз данных (например, через xp_cmdshell в Microsoft SQL Server). SQL-инъекции классифицируются как атаки на уровень данных и входят в число самых опасных уязвимостей веб-приложений по версии OWASP Top 10.

История

Термин «SQL-инъекция» впервые был введён в 1998 году исследователем безопасности Джеффом Форристалом (Jeff Forristal), который опубликовал статью в журнале Phrack, описывающую технику внедрения SQL-кода через параметры URL. Однако сама концепция атаки существовала и ранее: ещё в середине 1990-х годов программисты замечали, что некорректная обработка кавычек в SQL-запросах может приводить к неожиданным результатам.

Первые широко известные случаи эксплуатации SQL-инъекций относятся к началу 2000-х годов. В 2005 году произошла одна из крупнейших утечек данных в истории — атака на систему обработки кредитных карт компании CardSystems Solutions, в результате которой были скомпрометированы данные 40 миллионов держателей карт. Расследование показало, что причиной утечки стала SQL-инъекция. В 2008 году группа хакеров, известная как «Team Ghost», использовала SQL-инъекции для взлома сайтов правительственных организаций Китая и Тайваня.

С развитием фреймворков и ORM (Object-Relational Mapping) количество SQL-инъекций снизилось, но проблема остаётся актуальной: по данным отчётов Positive Technologies за 2023 год, SQL-инъекции по-прежнему входят в тройку самых частых векторов атак на веб-приложения в России.

Классификация

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

По способу получения данных

Классические (in-band) инъекции — атакующий получает результат атаки непосредственно в ответе от сервера. Это самый простой для эксплуатации тип. Пример: внедрение в параметр id=1 UNION SELECT username, password FROM users — результат выводится на странице.

Слепые (blind) инъекции — ответ сервера не содержит данных из базы, но атакующий может определить истинность или ложность условия по косвенным признакам (времени ответа, коду ошибки, изменению содержимого страницы). Делятся на:

• Boolean-based blind — атака основана на анализе разницы в ответах сервера при истинном и ложном условии (например, ' OR 1=1 -- vs ' OR 1=2 --).
• Time-based blind — атака использует задержки в ответе, вызванные функциями вроде SLEEP() или WAITFOR DELAY.

Out-of-band инъекции — данные передаются по альтернативному каналу (например, через DNS-запросы или HTTP-запросы на внешний сервер). Используются, когда прямой вывод невозможен, а слепые инъекции слишком медленны.

По типу внедрения

Инъекции первого порядка (first-order) — вредоносный код вводится непосредственно в запрос, который выполняется немедленно.

Инъекции второго порядка (second-order) — вредоносный код сохраняется в базе данных (например, в поле имени пользователя) и выполняется только при последующем обращении к этим данным. Этот тип сложнее обнаружить, так как атака происходит не сразу.

По месту атаки

• Входные формы (логин, поиск, регистрация).
• Параметры URL (GET-запросы, например, ?id=1).
• Cookie (значения, хранящиеся в браузере).
• HTTP-заголовки (User-Agent, Referer, X-Forwarded-For).

Устройство и механизм атаки

Основной принцип

SQL-запросы в веб-приложениях часто строятся путём конкатенации строк. Например, уязвимый код на PHP:

``php $id = $_GET['id']; $query = "SELECT * FROM products WHERE id = " . $id; ``

Если злоумышленник передаёт id=1 OR 1=1, запрос превращается в:

``sql SELECT * FROM products WHERE id = 1 OR 1=1 ``

Условие 1=1 всегда истинно, поэтому запрос возвращает все записи из таблицы, а не только одну.

Типичные приёмы

Обход аутентификации: внедрение в форму логина ' OR '1'='1' -- может привести к тому, что условие WHERE username='admin' AND password='...' станет истинным для любой записи.

UNION-инъекция: позволяет объединить результаты исходного запроса с данными из другой таблицы. Например:

``sql ' UNION SELECT username, password FROM users -- ``

Комментарии: символы -- (двойной дефис) в SQL или # в MySQL позволяют закомментировать остаток запроса, отсекая лишние условия.

Слепые инъекции: атакующий использует функции SUBSTRING(), ASCII() и SLEEP() для посимвольного извлечения данных. Например:

``sql ' OR IF(ASCII(SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1))>100, SLEEP(5), 0) -- ``

Если задержка в 5 секунд происходит, значит, первый символ пароля имеет ASCII-код больше 100.

Эксплуатация на уровне сервера

В некоторых СУБД (например, Microsoft SQL Server) SQL-инъекция может быть расширена до выполнения команд операционной системы через хранимые процедуры:

``sql '; EXEC xp_cmdshell('dir C:\'); -- ``

В PostgreSQL для этого используется COPY ... FROM PROGRAM, в Oracle — UTL_HTTP для отправки данных.

Применение и последствия

Цели атакующих

• Кража данных: извлечение паролей, персональных данных, банковских реквизитов, коммерческой тайны.
• Модификация данных: изменение цен, балансов, статусов заказов.
• Удаление данных: уничтожение таблиц или баз данных (вплоть до полного отказа системы).
• Эскалация привилегий: получение доступа к административной панели.
• Установка вредоносного ПО: через выполнение команд на сервере.

Реальные инциденты

• Heartland Payment Systems (2008): кража 130 миллионов номеров кредитных карт через SQL-инъекцию. Ущерб оценивается в 200 миллионов долларов.
• Sony PlayStation Network (2011): утечка данных 77 миллионов пользователей, включая имена, адреса и номера кредитных карт. Причиной стала SQL-инъекция в веб-приложении.
• TalkTalk (2015): атака на британского провайдера, в результате которой были украдены данные 157 000 клиентов. Компания потеряла 60 миллионов фунтов стерлингов.
• Российские компании: в 2022 году Positive Technologies зафиксировала SQL-инъекции в атаках на интернет-магазины, банки и государственные порталы. В одном из инцидентов злоумышленники через SQL-инъекцию получили доступ к базе данных клиентов крупного маркетплейса.

Методы защиты

Параметризованные запросы (prepared statements)

Основной и наиболее эффективный способ защиты. Вместо конкатенации строк используются плейсхолдеры, а данные передаются отдельно. Пример на Java:

``java String sql = "SELECT * FROM users WHERE username = ?"; PreparedStatement stmt = connection.prepareStatement(sql); stmt.setString(1, username); ResultSet rs = stmt.executeQuery(); ``

СУБД автоматически экранирует специальные символы, делая инъекцию невозможной.

Экранирование входных данных

Если параметризованные запросы невозможны (например, при динамическом построении запросов), необходимо экранировать специальные символы (кавычки, обратную косую черту). Однако этот метод менее надёжен, так как существует множество обходных путей.

Валидация входных данных

• Белый список: разрешены только строго определённые значения (например, числовые ID).
• Чёрный список: запрещены известные вредоносные символы (', ;, --). Не рекомендуется как единственная защита, так как чёрный список легко обойти.

Принцип наименьших привилегий

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

Использование ORM и фреймворков

Современные ORM (Hibernate, Entity Framework, Django ORM) по умолчанию используют параметризованные запросы. Однако разработчик должен избегать «сырых» SQL-запросов (raw queries) в обход ORM.

Брандмауэры веб-приложений (WAF)

WAF (например, ModSecurity, AWS WAF) анализируют входящие запросы и блокируют подозрительные шаблоны (например, ' OR 1=1). Однако WAF не является панацеей: опытные атакующие могут обойти его с помощью обфускации кода.

Регулярные аудиты и тестирование

• Статический анализ кода (SAST): поиск уязвимых мест в исходном коде.
• Динамическое тестирование (DAST): сканирование работающего приложения на наличие SQL-инъекций.
• Пентесты: ручное тестирование безопасности с попыткой эксплуатации уязвимостей.

Интересные факты

• SQL-инъекции могут быть автоматизированы с помощью инструментов вроде sqlmap, который позволяет извлекать данные из базы без ручного написания запросов.
• В некоторых СУБД (например, SQLite) SQL-инъекция может быть использована для выполнения произвольного кода через встроенные функции.
• В 2010 году хакер под псевдонимом «Hacker Croll» использовал SQL-инъекцию для взлома Twitter-аккаунтов, в том числе аккаунта Барака Обамы.
• SQL-инъекции остаются актуальными даже в 2024 году: по данным отчёта Akamai, 65% атак на веб-приложения в 2023 году были связаны с SQL-инъекциями или межсайтовым скриптингом (XSS).

Источники

• OWASP Top 10 — 2021: A03:2021 — Injection
• Positive Technologies: «Актуальные киберугрозы: Итоги 2023 года»
• Jeff Forristal, «NT Web Technology Vulnerabilities», Phrack Magazine, 1998
• «SQL Injection Attacks and Defense» by Justin Clarke, 2012
• Akamai Security Research: «State of the Internet / Security Report 2023»