Sql инъекции все способы

Базовые sql-инъекции в приложениях, использующих язык SQL. Руководство для чайников

Примечание переводчика

Данная работа является переводом части работы Chris Anley Advanced SQL Injection In SQL Server Applications. (прямая ссылка для скачивания)
В последующих статьях, при наличии свободного времени, данный перевод будет доведен до конца.

P.S. Перевод будет интересен более в образовательных и исторических целях.

Оригинальное название статьи: Продвинутые SQL-инъекции в приложениях, использующих язык SQL.

Аннотация

Введение

Structured Query Language (SQL) — это структурированный язык, используемый для взаимодействия с базами данных. Существует множетсво «диалектов» языка SQL, но сегодня, в основном, все они построены на основе стандарта SQL-92, один из ранних ANSI стандартов. Основной операционный блок SQL — запрос (query), который является совокупностью выражений, которые обычно возвращают совокупность результатов (result set). SQL выражения могут изменять структуру баз данных (используя выражения языков определения данных — DLL) и управлять их содержанием (используя выражения языков манипулирования данными — DML). В данной работе, мы рассмотрим transact-SQL, использующийся в Microsoft SQL Server.

SQL-инъекции возможны в том случае, когда злоумышленник может вставить свой SQL-код в запрос (query), для управления данными, которые отправляются в приложение.

Обычное SQL выражение выглядит следующим образом:

Это выражение берет «id», «forename» и «surname» из колонок таблицы «authors» и возвращает все строки в таблице. Выборка может быть ограниченна, определенным «автором», например:

Необходимо отметить, что в данном запросе строковые литералы разделены одинарной кавычкой. Предполагается, что «forename» и «surrname» являются данными, которые вводятся пользователем. В данном случае злоумышленник будет способен внести собственный SQL-запрос, путем добавления собственных значений в приложение. Например:

Тогда выражение примет следующий вид:

После того, как база данных попытается обработать подобный запрос будет возвращена следующая ошибка:

Причина ошибки будет заключаться в том, что введенная одиночная кавычка испортит структуру разделителей в запросе. Таким образом, база данных безуспешно попытается выполнить команду «hn», которая приведет к ошибке. В итоге, если злоумышленник введет в форму следующую информацию:

Таблица «authors» будет удалена, почему это произойдет мы рассмотрим позже.

Вам может показаться, что если мы будем удалять одиночные кавычки из формы ввода, а также «заменять» их, это может решить нашу проблему. И вы будете правы, однако существуют некоторые проблемы с использованием этого способа, в качестве решения данной задачи. Во-первых, не вся вводимая пользователем информация является «строками» (strings). Если пользовательская форма будет содержать «id» автора, который обычно является числом. Например, наш запрос может выглядеть следующим образом:

В данном случае взломщик беспрепятственно сможет добавить любое SQL-выражение в после численных данных. В других разновидностях SQL-запросов, используются различные разграничители. Например, в Microsoft Jet DBMS разграничителем будет символ «#». Во-вторых, «избегание» («escaping») одиночных кавычек вовсе не самый простой способ защиты, как это может показаться сперва. Подробнее об этом мы поговорим далее.

Приведем пример на основе страницы входа на основе Active Server Pages (ASP), которая при помощи 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 injection, SQLi, внедрение SQL-кода) часто называют самым распространённым методом атак на веб-сайты. Их широко используют хакеры и пентестеры в применении к веб-приложениям. В списке уязвимостей OWASP Топ-10 присутствуют SQL-инъекции, которые, наряду с другими подобными атаками, находятся на первом месте среди угроз, с которыми сталкиваются веб-проекты.

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

Этот материал рассчитан на абсолютных новичков, на тех, кто ничего не знает о SQL-инъекциях. Начнём мы с разбора основ, в которых необходимо ориентироваться перед разговором о SQLi. А именно, сначала мы поговорим о реляционных базах данных. Потом — о SQL, и о формировании SQL-запросов. И наконец — о том, как работают SQL-инъекции, и о том, почему они так опасны для веб-приложений.

Реляционные базы данных

Прежде чем говорить о SQL (и о SQL-инъекциях), нам надо познакомиться с реляционными базами данных (БД).

В реляционной БД хранятся взаимосвязанные данные, которые часто размещаются в таблицах. Каждая таблица содержит набор столбцов и строк.

Вот, например, таблица, которая называется users .

Эта таблица содержит три столбца (их ещё называют атрибутами): Id , User , Password . Строки таблицы называют записями. В нашей таблице имеется две записи.

Беглый взгляд на эту таблицу позволяет сделать вывод о том, что в ней, вероятно, хранятся учётные данные пользователей некоей системы. После того, как пользователь вводит имя и пароль в форме аутентификации, веб-приложение сверяет эти данные с вышеприведённой таблицей. Именно после того, как данные пользователя найдены (или не найдены) в таблице, приложение узнаёт о том, следует ли, например, дать этому пользователю возможность работать с ресурсами проекта, предназначенными только для зарегистрированных пользователей.

Это — лишь простой пример. Реляционные базы данных обычно представляют собой гораздо более сложные конструкции, в состав которых входит множество таблиц, в каждой из которых имеется много атрибутов и записей (иногда их количество исчисляется миллионами). Таблицы могут быть связаны с другими таблицами.

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

SQL (Structured Query Language, язык структурированных запросов) — это язык, который предназначен для работы с реляционными БД. С его помощью, взаимодействуя с базой данных, можно просматривать, добавлять, обновлять, удалять данные.

▍Основные SQL-выражения

Веб-приложение взаимодействует с базой данных, пользуясь SQL-выражениями. Каждое такое выражение начинается с некоей команды.

Вот пример, который поможет нам разобраться в синтаксисе подобных выражений:

Здесь SQL-выражение начинается с команды SELECT , которая позволяет извлекать данные из БД.

За командой SELECT идёт символ звёздочки ( * ). Тут он олицетворяет все столбцы таблицы. Это значит, что мы хотим извлечь данные из всех столбцов.

Если вы хоть немного понимаете английский, то ключевое слово FROM в дополнительных пояснениях не нуждается.

И, наконец, users — это имя таблицы, из которой мы хотим извлечь данные.

Если «перевести» вышеприведённое SQL-выражение на обычный язык, то получится следующее:

Давайте теперь сделаем вышеописанное SQL-выражение немного интереснее:

В данном случае мы указываем на то, что хотим получить лишь запись, в поле user которой имеется имя пользователя Fyodor . Все остальные записи таблицы нас не интересуют.

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

▍Команды и ключевые слова SQL

Теперь, в завершение этого раздела, хочу рассказать о некоторых наиболее часто используемых командах и ключевых словах SQL. Для того чтобы понять то, о чём речь пойдёт дальше, знать все эти команды и ключевые слова вам необязательно, но я настоятельно рекомендую вам поближе с ними познакомиться после того, как вы дочитаете эту статью.

• SELECT : получение данных из таблицы.
• INSERT INTO : добавление записи в таблицу.
• UPDATE : обновление содержимого записи таблицы.
• DELETE : удаление записи из таблицы.
• CREATE TABLE : создание новой таблицы.
• WHERE : фильтрация записей по заданному условию.
• ORDER BY : сортировка данных, полученных с помощью SELECT .

Теперь, разобрав основы, переходим к нашей основной теме.

SQL-инъекции

Как уже было сказано, SQL-инъекции — это разновидность атаки на веб-приложения. В ходе проведения такой атаки делается попытка модификация SQL-выражения, которое приложение отправляет базе данных. Выполняется атака путём подстановки особым образом подготовленных данных в поля ввода, которые может заполнять пользователь.

Для того чтобы вышесказанное стало бы понятнее — рассмотрим пример.

▍Простая атака с использованием SQL-инъекции

Предположим, имеется форма аутентификации, которая предлагает пользователю ввести в её поля имя и пароль. Приложение предоставляет пользователям доступ к закрытым ресурсам после проверки введённых данных. Если говорить точнее, то приложение отправляет к базе данных SQL-запрос, направленный на проверку наличия там тех данных, которые ввёл пользователь. Используемое при этом SQL-выражение может выглядеть примерно так:

Если вы внимательно читали статью, то вы без труда поймёте эту конструкцию. Она извлекает из таблицы users все записи, фильтруя их по имени пользователя (поле username ) ProvidedUsername и по паролю ( password ) ProvidedPassword . Если в таблице имеется запись, удовлетворяющая этим двум условиям — это значит, что пользователь ввёл верные имя и пароль. Приложение, в результате, даст такому пользователю доступ к закрытым ресурсам.

Теперь представьте, что вместо того, чтобы ввести в поле формы имя, пользователь вводит туда следующее:

А затем, в качестве пароля, вводит произвольный набор символов (то, что будет введено в поле для пароля, значения не имеет; ниже мы с этим разберёмся).

После этого приложение формирует такое SQL-выражение:

База данных, обрабатывая такой запрос, вернёт любую запись из таблицы users , в поле username которой находится a . Запись будет возвращена и в том случае, если истинным является выражение 1=1 .

Но выражение 1=1 всегда истинно, поэтому этот запрос приведёт к получению всех записей из таблицы.

Кроме того, так как два дефиса в SQL используются для оформления однострочных комментариев, всё, что идёт после них, окажется закомментированным, то есть — соответствующие команды базой данных обрабатываться не будут. Если выделить ту часть SQL-запроса, которая будет выполнена базой данных, то получится следующее:

База данных, обрабатывая этот запрос, вернёт список записей, не являющихся NULL-значениями, и, в результате, веб-приложение даст пользователю доступ к закрытым ресурсам.

Итоги

Мы рассмотрели лишь один пример SQL-инъекции. Но существует и множество других способов внедрения SQL-кода в веб-приложения. Если вы хотите посмотреть больше примеров — рекомендую взглянуть на этот материал, опубликованный на сайте Netsparker, и на этот материал с сайта PortSwigger.

Если вы хотите попрактиковаться в деле выполнения атак на веб-приложения с использованием SQL-инъекций — попытайте удачу в варгейме Natas на OverTheWire. Если вы не знаете о том, что это такое — вот моя статья об этом.

Как вы защищаете свои веб-проекты от SQL-инъекций?

Источник