Большинство атак на БД через веб

Информационные и телекоммуникационные технологии: образование, наука, практика:
Труды Международной научно-практический конференции. - 2012. - Т. 2. - С. 245-248
ЗАЩИТА MS SQL SERVER ОТ SQL-ИНЪЕКЦИЙ
Айтхожаева Е.Ж., Каримов Е.А.
Казахский Национальный Технический Университет имени. К.И.Сатпаева, кафедра
Вычислительной техники, Алматы, Казахста, ait_evg@mail.ru
Abstract
This paper represents methods and means of defense against SQL- injection for MS SQL
Server, is instructed to properly configure the database system manager.
Аннотация
В статье рассматриваются принцип действия SQL-инъекций, методы и средства
защиты от SQL-инъекций для MS SQL Server и организация защиты от них.
Базы данных (БД) являются обязательным компонентом информационных систем
любого уровня и класса, а широкое применение в информационных системах технологии
клиент-сервер обусловило появление на рынке большого количества серверов баз данных,
постоянно подвергающихся атакам злоумышленников как извне, так и изнутри.
Большинство атак на БД производится внедрением вредоносного кода в запросы SQL, так
называемые SQL-инъекции.
Количество
случаев,
связанных с несанкционированным доступом к
информационным системам и утечкой конфиденциальной информации вследствие SQLинъекций, неуклонно растет с каждым годом.
SQL-инъекция – это атака, при которой злоумышленником производится вставка
вредоносного кода в строки, передающиеся на сервер БД для синтаксического анализа и
выполнения. Успешная реализация данной атаки позволяет обойти систему безопасности
приложения и сервера БД и получить доступ к конфиденциальной информации, которая
содержится в БД, а также к функциональным возможностям СУБД и в некоторых случаях
– доступ к операционной системе сервера, на котором функционирует СУБД. В этом
случае злоумышленник получает доступ не только к конфиденциальной информации,
содержащейся в БД, но и доступ к командам операционной системы сервера СУБД, что
дает злоумышленнику возможность использовать «взломанный» сервер для последующих
атак на другие сервера и приложения, расположенные в корпоративной сети организации.
Как правило, SQL-инъекции рассматривают применительно к web-приложениям, на
самом деле данным уязвимостям подвержены любые клиент-серверные и сервисориентированные приложения, работающие с СУБД. На сегодняшний день существует
большое количество техник эксплуатации SQL-инъекций для различных СУБД и
приложений на их основе [1].
В данной статье обсуждается принцип действия SQL-инъекций и организация
защиты баз данных в распространенном сервере баз данных MS SQL Server от SQLинъекций.
Принцип атаки внедрения вредоносного кода в запросы SQL в web-приложениях
основывается на использовании web-интерфейса. SQL-инъекции – метод взлома, который
использует введение SQL запросов/команд через web-страницы. Многие web-страницы
используются для ввода параметров, предназначенных для SQL запросов к базам данных,
Web-пользователями. Это могут быть страницы подобно ASP, JSP, CGI, или PHP Web,
которые используют параметры. Обычно для этого метода используются страницы,
которые запрашивают у пользователя данные, например страница поиска, обсуждений, и
т.д.
Если атакующий на сайт нашел изъян в приложении для внедрения SQL-инъекций,
он с помощью запросов сможет управлять удаленным MS SQL Server, к которому у него
нет санкционированного доступа.
Существует определенная классификация SQL-инъекций. Они делятся на:
- внедрение в строковые параметры, используемые в SQL-командах, кода, который
изменяет условия выборки и дает злоумышленнику несанкционированный доступ к
данным;
- использование оператора UNION в параметре для объединения и выполнения
легального запроса с нелегальным запросом;
- использование объединения строк;
- экранирование «хвоста» запроса, ограничивающего выборку данных, путем
превращения его в комментарий;
- расщепление SQL-запроса с помощью символа «;», что дает возможность
выполнить несколько команд (несанкционированных) в одном санкционированном
запросе.
Организованная защита от SQL-инъекций должна лишить злоумышленника
возможности выполнять указанные выше действия. Для этого используются следующие
методы:
-фильтрация строковых параметров;
-усечение входных параметров;
-использование параметризованных команд;
-использование хранимых процедур;
-использование функции блокировки;
-создание менее привилегированного пользователя;
- контроль сообщений об ошибках.
Для проверки указанных методов защиты была разработана и реализована в MS SQL
Server тестовая БД для Отдела сервисного обслуживания компьютерной техники. В
инструментальной среде Visual Studio 2010, с использованием HTML и языка серверных
сценариев ASP разработано Web-приложение для работы с данной БД [2]. При этом были
использованы указанные выше методы защиты от SQL-инъекций. Выполненное
тестирование с использованием SQL-инъекций показало эффективность ниже указанных
методов защиты.
Фильтрация строковых параметров.
Для защиты от данного типа атак необходимо тщательно фильтровать входные
параметры, значения которых будут использованы для построения SQL-запроса.
Чтобы внедрение кода было невозможно для СУБД MS SQL Server, требуется брать
в кавычки все строковые параметры. После получения параметров перед их
использованием необходимо выполнить их преобразование. В самом параметре заменяют
кавычки на \", апостроф на \', обратную косую черту на \\, каждую одиночную кавычку на
пару одиночных кавычек (это называется «экранировать спецсимволы»), таким образом,
гарантируя, что они не будут спутаны с разделителями в SQL-операторе.
Замена
апострофов
предотвращает
преждевременное
закрытие
строки
злоумышленником. Однако при построении динамического оператора SQL, который
включает числовые значения, для атаки внедрением SQL понадобится ли шь одиночный
пробел. Эта уязвимость часто (и опасно) игнорируется.
Усечение входных параметров.
Для внесения изменений в логику выполнения SQL-запроса требуется внедрение
достаточно длинных строк. Если максимальная длина корректного значения параметра
невелика, то одним из методов защиты может быть максимальное усечение длины
входных параметров, т.е.использовать ограничение на длину вводимого параметра.
Это уменьшит вероятность того, что в поле ввода кто-то сможет вставить
нежелательный большой фрагмент сценария. В дополнение к этому можно использовать
элементы управления проверкой достоверности ASP.NET, чтобы блокировать очевидно
недопустимые данные (такие как текст, пробелы или специальные символы в числовых
значениях).
Использование параметризованных команд.
Параметризованная команда - это просто команда, которая использует символызаполнители в тексте SQL. Заполнитель указывает место для динамически применяемых
значений, которые затем пересылаются через коллекцию Parameters объекту Command.
Например, следующий оператор SQL:
SELECT * FROM Customers WHERE CustomerlD = 'ALFKI'
необходимо заменить на:
SELECT * FROM Customers WHERE CustomerlD = @CustID.
Заполнители добавляются раздельно и автоматически кодируются.
Синтаксис параметризованных команд у различных поставщиков выглядит немного
по-разному. В поставщике данных SQL Server предусматривается использование
именованных заполнителей (с уникальными именами). У поставщика OLE DB каждое
жестко закодированное значение заменяется вопросительным знаком. В любом случае
необходимо предоставить объект Parameter для каждого параметра, который вставляется в
коллекцию Command.Parameters. При работе с поставщиком OLE DB следует убедиться,
что параметры добавляются в том же порядке, в котором они появляются в строке SQL.
Этого не требует поставщик данных SQL Server, поскольку соответствие между
параметрами и заполнителями задается с помощью имен.
Использование хранимых процедур.
Хранимая процедура – набор SQL-инструкций, который компилируется один раз и
хранится на сервере. У хранимых процедур могут быть входные и выходные параметры и
локальные переменные, в них могут производиться числовые вычисления и операции над
символьными данными, результаты которых могут присваиваться переменным и
параметрам. Хранимые процедуры легко сопровождать. Например, можно
оптимизировать команды в хранимой процедуре без перекомпиляции приложения,
использующего ее. Также они стандартизуют логику доступа к данным в одном месте — в
базе данных, облегчая ее многократное использование согласованным образом разными
приложениями.
Они позволяют реализовать более безопасное обращение с базой данных. Например,
можно позволить учетной записи Windows, которая запускает код ASP.NET, использовать
определенные хранимые процедуры, но ограничить доступ к лежащим в их основе
таблицам.
При использовании хранимых процедур по сети передаются только параметры, а вся
логика использования этих параметров недоступна злоумышленнику, что затрудняет ему
подбор нелегальных параметров.
Использование функции блокировки.
Необходимо использовать функцию MSSQLreal_escape_string() для обработки
внешних данных. Например:
function MSSQLreal_escape_string($string) {
return str_replace("'","''", $string);
Эта встроенная функция способна предотвратить SQL-инъекции в большинстве
случаев.
Можно
попробовать
внедрить
SQL-код
после
использования
MSSQLreal_escape_string() и тестировать на уязвимости. Эта функция отвергает
множество методов атак, используемых злоумышленниками.
Создание менее привилегированного пользователя БД.
В большинстве случаев посетителям веб-сайтов не нужно удалять или обновлять
информацию. Обычно пользователю нужно запросить данные (SELECT) или оставить
заказ (INSERT).
Таким образом, лучше создать несколько различных пользователей, ограничить
права учетной записи, от имени которой выполняется доступ к базе данных, чтобы она не
имела прав доступа к другим базам данных или запуска расширенных системных
хранимых процедур.
Тем не менее, это не решает проблему внедрения SQL-сценариев, поскольку
процесс, используемый для подключения к базе данных, почти всегда требует более
широких привилегий, чем те, что выделяются отдельному пользователю.
Ограничивая учетную запись, можно предотвратить атаки, связанные, например, с
удалением таблиц, но нельзя предотвратить атаки, связанные с хищением информации.
Контроль сообщений об ошибках.
Когда приложение отображает сообщения об ошибках, они не должны содержать
информацию, которая могла бы помочь злоумышленникам атаковать систему. Например,
если попытка приложения войти в базу данных закончилась неудачей, оно не должно
отображать сообщение об ошибке, включающее имя пользователя.
Существует несколько способов контроля над сообщениями об ошибках, включая
следующие.
Настроить приложение таким образом, чтобы оно не выводило подробных сведений
об ошибках для удаленных пользователей. При необходимости, сообщения об ошибках
можно перенаправить на страницу приложения.
Включить обработку ошибок и создать собственные сообщения об ошибка х. В
обработчике ошибок можно проверить, является ли пользователь легальным, и
действовать соответствующим образом.
Создать глобальный обработчик ошибок на уровне страницы или приложения,
который перехватывает все необработанные исключения и передает их н а универсальную
страницу ошибок. Таким образом, даже если данная проблема не была предусмотрена,
пользователи не будут видеть страницу исключений.
Дополнительные меры по предотвращению SQL атак.
Никогда не стоит хранить пароли в базе данных в открытом виде, обязательно
следует шифровать их (например, функцией sha1). С помощью SQL-инъекции можно
получить данные о паролях из базы данных, а если они будут зашифрованы, то
вероятность того, что злоумышленник сможет ими воспользоваться, намного
уменьшается.
Для обеспечения конфиденциальности логина и пароля для доступа к базе данных,
функции подключения к базе данных лучше хранить в отдельном файле и подключать его
на каждой странице сайта.
Наиболее правильный способ – придерживаться стандартов безопасного
программирования при написании приложений. Если код приложения уже написан,
необходимо провести аудит для обнаружения уязвимостей. Так же рекомендуется
обратиться к некоторым средствам автоматизации, которые предназначены для
обнаружения таких типов проблем.
Даже если закрыты все известные уязвимости, рекомендуетя отключение
неиспользуемых функциональных возможностей SQL сервера (если они действительно не
нужны).
Необходимо запретить специальные запросы через OLEDB от SQL сервера.
Возможность осуществления этих запросов контролируются установкой значения
DisallowAdhocAccess в системном реестре.
Список литературы
1. Егоров М. Выявление и эксплуатация SQL-инъекций в приложениях. // Эшелон.
2011, № 2.
2. Мак-Дональд М. Microsoft ASP.NET 4 с примерами на С# 2010 для
профессионалов, 4-е изд. : Пер. с англ. — М. : ООО "И.Д. Вильямс", 2011. -1424 с.