Что такое SQL-инъекция? Определение и описание
Атаки с SQL-инъекцией основаны на одном из старейших классов уязвимостей в веб-приложениях. Они известны ИБ-экспертам с конца 90-х годов, но все еще остаются актуальными. В этой статье мы расскажем, что эти атаки собой представляют, как они работают и как их можно предотвратить.
SQL-инъекция – определение и описание
SQL-инъекция или SQLi – уязвимость, которая позволяет атакующему использовать фрагмент вредоносного кода на языке структурированных запросов (SQL) для манипулирования базой данных и получения доступа к потенциально ценной информации. Атаки на основе таких уязвимостей – одни из самых распространенных и опасных: они могут быть нацелены на любое веб-приложение или веб-сайт, которые взаимодействуют с базой данных SQL (а подавляющее большинство баз данных реализованы именно на SQL).
Как происходят атаки на основе SQL-инъекции?
Чтобы понять принцип действия SQL-инъекции, сначала стоит разобраться, что представляет собой язык SQL. SQL – это язык построения запросов, который применяется в программировании для чтения, изменения и удаления информации, хранящейся в реляционных базах данных. Так как большинство веб-сайтов и веб-приложений взаимодействуют с базами данных SQL, атака на основе SQL-инъекции может нанести серьезный ущерб организации.
SQL-запрос – это запрос, направленный в базу данных для выполнения определенной операции или функции, такой как извлечение данных или исполнение SQL-кода. Например, запрос может осуществлять передачу учетных данных пользователя через веб-форму для доступа к сайту. Обычно подобные веб-формы сконфигурированы таким образом, чтобы принимать только определенные типы данных, такие как имя пользователя и (или) пароль. Введенная информация сверяется с базой данных. Если все совпадает, пользователь сможет войти на сайт. А если нет – в доступе будет отказано.
Ситуация опасна тем, что большинство веб-форм не имеют механизмов, которые бы исключали ввод дополнительной информации в поле. Это дает злоумышленникам возможность передать в базу данных собственные запросы через поля ввода формы. Они могут использовать эту уязвимость в разных преступных целях, начиная с кражи конфиденциальных данных и заканчивая манипулированием сведениями в базе.
Так как подавляющее большинство веб-сайтов и серверов полагаются на базы данных, SQL-инъекции являются одними из самых давних и распространенных видов кибератак. В сообществе киберпреступников появилось несколько разработок, повышающих вероятность таких атак: прежде всего речь идет об инструментах, которые позволяют обнаружить уязвимое место для SQL-инъекции. Соответствующие утилиты представлены в свободном доступе как проекты с открытым исходным кодом. Достаточно нажать нужную кнопку, и за считаные минуты будет реализована атака, позволяющая заполучить доступ к любой таблице или столбцу базы данных.
Симптомы SQLi-атаки
Успешно проведенная атака с SQL-инъекцией может вообще никак себя не проявлять. Тем не менее иногда можно заметить следующие симптомы:
- Получение избыточного числа запросов за короткий промежуток времени. Например, массовый поток электронных писем от формы обратной связи веб-сайта.
- Рекламные блоки, перенаправляющие пользователя на подозрительные веб-сайты.
- Странные всплывающие окна и сообщения об ошибках.
Типы SQL-инъекций
В зависимости от способа получения доступа к данным бэкенд-сервера и потенциальных масштабов ущерба SQL-инъекции можно разделить на три категории:
Внутриполосная атака (In-band SQLi)
Это самый простой вид атаки для злоумышленников, так как для реализации атаки и сбора результатов используется один и тот же канал связи. Этот тип SQLi-атак разделяют на два подвида:
- Атака на основе ошибок (Error-based SQLi). При такой атаке действия злоумышленника приводят к тому, что база данных генерирует сообщение об ошибке. На основе полученных сообщений об ошибках злоумышленник пытается сформировать представление об инфраструктуре базы данных.
- Атака на основе объединения (Union-based SQLi). Атакующий получает необходимые данные путем объединения нескольких инструкций SELECT в единый ответ HTTP с помощью SQL-оператора UNION.
Инференциальная атака (Inferential SQLi, также известна как «слепая SQL-инъекция»)
При таких атаках злоумышленники изучают ответы и поведение сервера после отправки наборов данных, чтобы узнать больше о структуре базы данных. При этом никакие записи из базы данных веб-сайта не передаются злоумышленнику, и он не видит их в том же канале связи, как в случае внутриполосной атаки (этим и объясняется название «слепая SQL-инъекция»). Такие атаки разделяют на два подвида:
- Слепая атака, основанная на времени (Time-based SQLi). Атакующие направляют SQL-запрос к базе данных, вынуждая ее сделать задержку на несколько секунд, прежде чем она подтвердит или опровергнет полученный запрос.
- Булевая слепая атака (Boolean SQLi). Атакующие делают SQL-запрос к базе данных, ожидая получить результат в виде утвердительного или отрицательного ответа.
Внеполосная атака (Out-of-band SQLi)
Такая атака происходит в двух случаях:
- когда атакующие не могут провести атаку и собрать данные через один и тот же канал связи; или
- когда сервер работает слишком медленно или нестабильно, чтобы достичь нужного результата.
Последствия атак на основе SQL-инъекции
Успешная SQLi-атака может нанести серьезный ущерб бизнесу. SQL-инъекция может привести к следующим последствиям:
- Раскрытие конфиденциальных данных. Атакующие могут заполучить конфиденциальную информацию, хранящуюся на SQL-сервере.
- Компрометация целостности данных. Злоумышленники могут отредактировать или удалить информацию в вашей системе.
- Нарушение приватности пользователей. В зависимости от того, какие данные хранятся на SQL-сервере, атака может привести к раскрытию конфиденциальных пользовательских данных – адресов, номеров телефонов и сведений банковских карт.
- Получение злоумышленниками административного доступа к вашей системе. Если у пользователя базы данных есть привилегии администратора, с помощью вредоносного кода атакующий может заполучить доступ к системе.
- Получение злоумышленниками общих прав доступа к вашей системе. Если для проверки имен пользователей и паролей применяются слишком простые SQL-команды, атакующий сможет заполучить доступ к вашей системе, даже не имея действующих учетных данных пользователя. После этого злоумышленник сможет добраться до конфиденциальной информации и изменить ее, создав большие проблемы для вашего бизнеса.
Ущерб от SQLi-атак не только финансовый. Успешная атака может привести к репутационным потерям и утрате доверия клиентов, если произойдет кража персональной информации – имен, адресов, телефонных номеров и данных кредитных карт. Вернуть доверие клиентов гораздо сложнее, чем его потерять.
Примеры SQL-инъекций
За годы существования этого класса уязвимостей от SQLi-атак пострадало множество организаций. Приведем некоторые громкие случаи:
Fortnite, 2019 г.Fortnite – это онлайн-игра с аудиторией, насчитывающей более 350 млн игроков. В 2019 году была обнаружена уязвимость для SQL-инъекции, которая позволила злоумышленникам получить доступ к пользовательским учетным записям. Уязвимость впоследствии закрыли.
Cisco, 2018 г.
В 2018 году была найдена уязвимость для SQL-инъекции в Cisco Prime License Manager. Брешь позволила атакующим заполучить доступ к командной оболочке систем, на которых был развернут диспетчер лицензий Cisco. Компания Cisco впоследствии закрыла эту уязвимость.
Tesla, 2014 г.
В 2014 году специалисты по кибербезопасности заявили об успешном взломе веб-сайта Tesla методом SQL-инъекции – им удалось получить административные привилегии и украсть пользовательские данные.
Вопросы и ответы об SQLi-атаках
Часто задаваемые вопросы об SQLi-атаках:
Что представляет собой атака на основе SQL-инъекции?
Атака на основе SQL-инъекции подразумевает внедрение вредоносного SQL-кода с целью манипулирования серверной базой данных и доступа к закрытой информации. Сюда могут относиться конфиденциальные данные компании, списки пользователей или сведения о клиентах. SQL – это аббревиатура от Structured Query Language (язык структурированных запросов). Иногда понятие «атака с применением SQL-инъекции» сокращают до SQLi.
Что происходит в процессе SQL-инъекции?
С помощью SQLi-атаки злоумышленники могут подменять цифровую личность, изменять существующие данные, извлекать конфиденциальные данные, удалять данные или делать их недоступными, а также получать права администратора сервера базы данных. SQL-инъекция способна нанести серьезный ущерб бизнесу, включая утрату доверия клиентов в случае утечки конфиденциальных данных.
Насколько распространены атаки на основе SQL-инъекции?
Злоумышленники довольно часто прибегают к SQLi-атакам, ведь их относительно просто реализовать, а успешная атака может принести большую прибыль. Однозначной статистики на этот счет нет, но по усредненным оценкам, SQL-инъекции составляют основную часть атак на программные системы. По данным сообщества Open Web Application Security Project, атаки на основе внедрения кода, к которым также относится SQL-инъекция, являлись третьим по значимости риском безопасности для веб-приложений в 2021 году.
Как предотвратить атаку на основе SQL-инъекции?
Вот ключевые принципы, которые помогут компаниям защитить свои веб-сайты и веб-приложения от потенциальной SQL-инъекции:
Проводите тренинги для персоналаПовышайте осведомленность о риске SQLi-атак среди членов команды, отвечающей за ваше веб-приложение, и проводите ролевые тренинги для всех пользователей.
Помните о контроле пользовательского вводаЛюбые пользовательские данные, указанные в SQL-запросе, несут потенциальные риски. До окончания проверки любые адреса, вводимые аутентифицированными и (или) внутренними пользователями, стоит обрабатывать так же, как и поступающие извне данные. Учетные записи, которые подключаются к базе данных SQL, должны обладать только минимально необходимым набором привилегий. По возможности применяйте списки разрешенных, а не запрещенных слов в ходе проверки и фильтрации пользовательского ввода.
Не забывайте об обновленияхДля максимальной защиты важно пользоваться самой последней версией вашей среды разработки, так как в старых версиях могут отсутствовать некоторые современные функции безопасности. Устанавливайте актуальные версии ПО и исправления безопасности сразу после их выпуска.
Проводите регулярные проверки веб-приложений
Пользуйтесь комплексными инструментами управления производительностью приложений. Регулярные проверки веб-приложений позволяют выявить и устранить потенциальные уязвимости до того, как они обернутся серьезными проблемами.
Используйте сетевой экранНередко для отсеивания SQLi-атак и прочих онлайн-угроз применяется сетевой экран веб-приложений (WAF). WAF фильтрует вредоносные SQL-запросы, сравнивая их с объемными и регулярно обновляемыми списками сигнатур. Обычно сигнатуры в этом списке описывают специфические векторы атак. Такой список регулярно обновляется после обнаружения новых уязвимостей.
SQL инъекции. Проверка, взлом, защита
SQL инъекция — это один из самых доступных способов взлома сайта.
Суть таких инъекций – внедрение в данные (передаваемые через GET, POST запросы или значения Cookie) произвольного SQL кода. Если сайт уязвим и выполняет такие инъекции, то по сути есть возможность творить с БД (чаще всего это MySQL) что угодно.
Как вычислить уязвимость, позволяющую внедрять SQL инъекции?
Довольно легко. Например, есть тестовый сайт test.ru. На сайте выводится список новостей, с возможностью детального просомтра. Адрес страницы с детальным описанием новости выглядит так: test.ru/?detail=1. Т.е через GET запрос переменная detail передаёт значение 1 (которое является идентификатором записи в табице новостей).
Изменяем GET запрос на ?detail=1′ или ?detail=1" . Далее пробуем передавать эти запросы серверу, т.е заходим на test.ru/?detail=1′ или на test.ru/?detail=1".
Если при заходе на данные страницы появляется ошибка, значит сайт уязвим на SQL инъекции.
Пример ошибки, возникающей при проверке уязвимости 
Возможные SQL инъекции (SQL внедрения)
1) Наиболее простые — сворачивание условия WHERE к истиностному результату при любых значениях параметров.
2) Присоединение к запросу результатов другого запроса. Делается это через оператор UNION.
3) Закомментирование части запроса.
Практика. Варианты взлома сайта с уязвимостью на SQL внедрения
Итак, у нас есть уже упоминавшийся сайт test.ru. В базе хранится 4 новости, 3 из которых выводятся. Разрешение на публикацию новости зависит от парметра public (если параметр содержит значение 1, то новость публикуется).
Список новостей, разрешённых к публикации
При обращении к странице test.ru/?detail=4, которая должна выводить четвёртую новость появляется ошибка – новость не найдена.
В нашем случае новость существует, но она запрещена к публикации. 
Но так как мы уже проверяли сайт на уязвимость и он выдавал ошибку БД, то пробуем перебирать возможные варианты запросов.
В адресной строке плюс (+) выполняет роль пробела, так что не пугайтесь
В итоге удача улыбнулась и два запроса (первый и третий) вернули нам детальное описание четвёртой новости 
Разбор примера изнутри
За получение детального описания новости отвечает блок кода:
$detail_id=$_GET[‘detail’];
$zapros="SELECT * FROM `$table_news` WHERE `public`=’1′ AND `id`=$detail_id ORDER BY `position` DESC";
Мало того, что $detail_id получает значение без какой либо обработки, так ещё и конструкция `id`=$detail_id написана криво, лучше придерживаться `id`=’$detail_id’ (т.е сравниваемое значение писать в прямых апострофах).
Глядя на запрос, получаемый при обращении к странице через test.ru/?detail=4+OR+1
SELECT * FROM `news` WHERE `public`=’1′ AND `id`=4 OR 1 ORDER BY `position` DESC
становится не совсем ясно, почему отобразилась 4-ая новость. Дело в том, что запрос вернул все записи из таблицы новостей, отсортированные в порядке убывания сверху. И таким образом наша 4-ая новость оказалась самой первой, она же и вывелась как детальная. Т.е просто совпадение.
Разбираем запрос, сформированный при обращении через test.ru/?detail=4+UNION+SELECT+*+FROM+news+WHERE+id=4 .
Тут название таблицы с новостями (в нашем случае это news) бралось логическим перебором.
Итак, выполнился запрос SELECT * FROM `news` WHERE `public`=’1′ AND `id`=4 UNION SELECT * FROM news WHERE ORDER BY `position` DESC . К нулевому результату первой части запроса (до UNION) присоединился результат второй части (после UNION), вернувшей детальное описание 4-ой новости.
Защита от SQL инъекций (SQL внедрений)
Защита от взлома сводится к базовому правилу «доверяй, но проверяй». Проверять нужно всё – числа, строки, даты, данные в специальных форматах.
Числа
Для проверки переменной на числовое значение используется функция is_numeric(n);, которая вернёт true, если параметр n — число, и false в противном случае.
Так же можно не проверять значение на число, а вручную переопределить тип. Вот пример, переопределяющий значение $id, полученное от $_GET[‘id_news’] в значение целочисленного типа (в целое число):
$id=(int)$_GET[‘id_news’];
Строки
Большинство взломов через SQL происходят по причине нахождения в строках «необезвреженных» кавычек, апострофов и других специальных символов. Для такого обезвреживания нужно использовать функцию addslashes($str);, которая возвращает строку $str с добавленным обратным слешем (\) перед каждым специальным символом. Данный процесс называется экранизацией.
$a="пример текста с апострофом ‘ ";
echo addslashes($a); //будет выведено: пример текста с апострофом \’
Кроме этого существуют две функции, созданные именно для экранизации строк, используемых в SQL выражениях.
Это mysql_escape_string($str); и mysql_real_escape_string($str);.
Первая не учитывает кодировку соединения с БД и может быть обойдена, а вот вторая её учитывает и абсолютно безопасна. mysql_real_escape_string($str); возвращает строку $str с добавленным обратным слешем к следующим символам: \x00, \n, \r, \, ‘, " и \x1a .
Магические кавычки
Магические кавычки – эффект автоматической замены кавычки на обратный слэш (\) и кавычку при операциях ввода/вывода. В некоторых конфигурациях PHP этот параметр включён, а в некоторых нет. Для того, что бы избежать двойного экранизирования символов и заэкранизировать данные по-нормальному через mysql_real_escape_string($str);, необходимо убрать автоматические проставленные обратные слеши (если магические кавычки включены).
Проверка включённости магических кавычек для данных получаемых из GET, POST или Куков организуется через функцию get_magic_quotes_gpc(); (возвращает 1 – если магические кавычки включены, 0 – если отключены).
Если магические кавычки вкючены (т.е обратные слеши добавляеются) и такое встречается чаще, то их нужно убрать. Это делается через функцию stripslashes($str); (возвращает строку $str без обратных слешей у кавычек и прямых апострофов).
В закючении привожу код с полной экранизацией строк для записи в БД
if(get_magic_quotes_gpc()==1)
<
$element_title=stripslashes(trim($_POST["element_title"]));
$element_text=stripslashes(trim($_POST["element_text"]));
$element_date=stripslashes(trim($_POST["element_date"]));
>
else
<
$element_title=trim($_POST["element_title"]);
$element_text=trim($_POST["element_text"]);
$element_date=trim($_POST["element_date"]);
>
$element_title=mysql_real_escape_string($element_title);
$element_text=mysql_real_escape_string($element_text);
$element_date=mysql_real_escape_string($element_date);
Статья была подготовлена на основе практических навыков по защите веб-систем. Теория дело хорошее, но практика важнее и главное она работает.
SQL-инъекции. Внедрение SQL-кода
SQL-инъекция (или «внедрение SQL-кода») — это метод получения несанкционированного доступа (разновидность взлома) к базе данных, при котором вредоносный код выполняется прямо из поля ввода в обычной форме.
Если SQL-инъекция прошла успешно, неавторизованные лица могут читать, создавать, обновлять или даже удалять записи из таблиц базы данных. Этот метод используется хакерами, пентестерами, тестировщиками и не только.
Пример №1: SQL-инъекция с использованием нескольких стейтментов
Предположим, у нас на сайте есть форма для поиска товаров по ID. Фрагмент PHP-кода поиска товара будет выглядеть примерно так:
Ничего подозрительного, верно?
Но что, если пользователь введет 20; DROP TABLE Products; ? Давайте посмотрим, как SQL интерпретирует это:
Данная команда удалит таблицу Products из базы данных. Это стало возможным, потому что большинство систем управления базами данных (СУБД) могут выполнять несколько команд одновременно.
Пример №2: SQL-инъекция с использованием всегда истинного условия
Другой способ выполнить SQL-инъекцию — это передать условие, которое всегда обрабатывается как true , чтобы данные всегда извлекались, несмотря ни на что.
Давайте взглянем на другой фрагмент PHP-кода, где у нас есть форма входа на наш веб-сайт, и пользователям нужно указать свой логин и пароль.
Лабораторная работа №1 «SQL-инъекции»
Атака может быть реализована против любой СУБД, поддерживающей SQL: MySQL, PostgreSQL, Oracle и т.д.
Далее рассмотрим ряд уязвимостей, приводящих к возможности реализации SQL-инъекции.
Некорректная обработка входных параметров
В случае, когда входные данные некорректно или недостаточно фильтруются, они могут содержать служебные символы и SQL-код. Вследствие этого злоумышленник может передать специально сформированную строку, которая будет подставлена в запрос к БД.
Пример уязвимого кода на PHP: Этот код получает значение параметра username, переданное пользователем. Затем это значение непосредственно используется для запроса к БД без какой-либо дополнительной обработки.
Для реализации SQL-инъекции в данном случае достаточно передать в качестве username следующую строку: ‘ OR ‘1’ = ‘1 . При этом выражение в условии запроса примет вид: username = » OR ‘1’ = ‘1’ . Очевидно, что оно всегда верно, поскольку всегда верно выражение ‘1’ = ‘1’ . Таким образом, запрос вернёт все строки из таблицы users.
Простейшей проверкой на недостаточную фильтрацию входных параметров служит подстановке символа одинарной (реже двойной или обратной) кавычки. Если входные данные обрабатываются некорректно, то такая подстановка гарантированно приведёт к ошибке, поскольку не будет обнаружено закрывающей кавычки. Аномальным поведением считается такое, при котором страницы, получаемые до и после подстановки кавычек, различаются, если при этом не получена страница с информацией о неверном формате параметров.
Несанкционированный доступ к данным
Язык SQL позволяет объединять результаты нескольких запросов при помощи оператора UNION. Это позволяют злоумышленнику получить несанкционированный доступ к данным в таблицах, не используемых в исходном запросе.
Приведённый выше код предназначен для отображения новости с заданным id из таблицы news.
Если передать в качестве id строку -1 UNION ALL SELECT username, password, NULL FROM users , то запрос не вернёт ни одной строки из таблицы news, поскольку строки с идентификатором -1 заведомо не существует. При этом посредством оператора UNION будут выбраны все строки из таблицы users.
Для успешного внедрения оператора UNION количество столбцов в выборках должно совпадать. Если количество столбцов в первой (исходной) выборке больше, то вторую необходимо дополнить соответствующим количеством констант (например, NULL).
Слепая SQL-инъекция
SQL-инъекция называется слепой (англ. blind SQL injection) в том случае, когда результат выполнения запроса недоступен злоумышленнику. При этом уязвимый веб-сайт по-разному реагирует на различные логические выражения, подставляемые в уязвимый параметр. Таким образом, злоумышленник может подобрать значения некоторых параметров (версия СУБД, текущее имя и права пользователя и т. д.), подставляя в запрос соответствующие логические выражения.
Рассмотрим следующий код: Его задача — вывести описание товара из таблицы catalog по указанному id. В случае, если товара с заданным id не существует, будет выведено соответствующее сообшение.
Если в качестве id передать строку 1 AND 1 = 1 , то условие запроса не изменится, поскольку выражение 1 = 1 всегда истинно. Если товар с id равным 1 существует, то в ответ будет получена страница с его описанием. Если затем в качестве id передать строку 1 AND 1 = 2 с заведомо ложным условием, то будет получено сообщение о том, что запрошенный товар не существует. Таким образом, можно подобрать значения некоторых параметров БД, например, условие SUBSTR(@@version, 1, 1) = 5 будет верным только если версия СУБД равна 5.
Особенности реализации SQL-инъекций
Иногда злоумышленник может провести атаку, но не может видеть более одной колонки результатов. В таком случае можно объединить несколько строк в одну при помощи конкатенации:
В некоторых случаях запрос, подверженный SQL-инъекции, имеет структуру, усложняющую или препятствующую внедрению операторов SQL. Например, следующий код: выбирает строки с указанным идентификатором author_id, сортирует их по дате и выводит 20 первых записей. Простая подстановка оператора UNION вместо author_id приведёт к ошибке из-за оставшейся части запроса: ORDER BY date DESC LIMIT 20 . В этом случае часть запроса необходимо экранировать при помощи символов комментария (--, /* или # в зависимости от СУБД). Часть строки, отделённая этими символами, будет проигнорирована и запрос успешно выполнится.
При этом важно помнить, что все скобки и кавычки должны быть закрыты, чтобы не вызывать ошибок при выполнении запроса. Если часть запроса экранируется, то соответствующие символы нужно передавать в явном виде.
Для разделения команд в языке SQL используется символ ; (точка с запятой). Внедряя этот символ в запрос, злоумышленник получает возможность выполнить несколько команд в одном запросе. Это позволяет выполнять операции, отличные от применяемых в исходном запросе, например, вставлять, изменять или удалять строки. Передав в качестве id строку -1; INSERT INTO users(username, password) VALUES (‘foo’, ‘bar’) , злоумышленник может несанкционированно вставить новую строку в таблицу users.
Предотвращение SQL-инъекций
Наиболее общими способами предотвращения SQL-инъекций являются фильтрация, экранирование и проверка всех входных данных. В языке PHP для этого могут применяться такие функции, как addslashes() и mysql_real_escape_string().
addslashes() экранирует специальные символы, добавляя к ним символ \ (обратный слэш). Таким образом, символ ' заменяется на \', " — на \" и т.д. Это позволяет избежать внедрения SQL-кода только в том случае, когда экранируемая строка в запросе заключена в кавычки.
mysql_real_escape_string() работает аналогично addslashes(), но учитывает особенности диалекта MySQL, экранируя некоторые дополнительные символы. Как и addslashes(), она работает только в случае, когда экранируемая строка заключена в кавычки.
Кроме того, в языке PHP существует ряд функций, позволяющих привести значение параметра к определённому типу. Например, функции intval() и floatval() позволяют преобразовать переменную к целому числу и числу с плавающей запятой соответственно. Это делает невозможным подстановку произвольных строк в запрос к БД.