Лекция 7. Вредоносные атаки на реляционные СУБД

**1-ый учебный вопрос: Вредоносные атаки на серверы баз данных.** Поскольку именно на серверах баз данных организации содержится самая чувствительная для организации информация, именно они часто подвергаются вредоносным атакам со стороны злоумышленников. Также, этим частым атакам способствует то, что настроенная по умолчанию или неправильно настроенная СУБД очень уязвима даже к самым простым в реализации типам атак. Результатом этих атак, как правило, является прямое изменение и порча данных, перехват управления сервером баз данных с целью требования выкупа, или просто уничтожение всех данных и нарушение работы сервера. Можно выделить три основных вида атак на серверы баз данных: изучение cookies в пользовательских приложениях баз данных, атаки blind-перебором и поиск уязвимостей СУБД с помощью SQL инъекций. Атака с модификацией cookies нацелена на перехват сеанса взаимодействия пользователя с сервером базы данных, с целью получить конфиденциальную информацию. ***Cookie*** - небольшой фрагмент данных, отправленный веб-сервером и хранимый на компьютере пользователя приложения баз данных. Веб-клиент (обычно веб-браузер) всякий раз при попытке открыть страницу соответствующего сайта пересылает этот фрагмент данных веб-серверу в составе HTTP-запроса. Применяется для сохранения данных на стороне пользователя, на практике обычно используется для: • аутентификации пользователя; • хранения персональных предпочтений и настроек пользователя; • отслеживания состояния сеанса доступа пользователя; • ведения статистики о пользователях. Очевидно, что доступная информация о сеансах пользователя или об аутентификации может быть очень интересна для злоумышленника, задумавшего получить доступ к информации, хранящейся в базе данных. Для понимания сути атаки необходимо разобраться с принципом работы cookie-файлов. Ниже приведен небольшой пример обмена данными сервера с пользовательским приложением. Подробная информация о принципах работы HTTP приводится в курсе дисциплины “Управление данными”. 1. Получив команду пользователя, браузер отправляет веб-серверу короткий текст с HTTP-запросом. Например, для доступа к странице http://www.example.org/index.html, браузер отправляет на сервер www.example.org следующий запрос: GET /index.html HTTP/1.1 HOST: www.example.org 2. Предположим, что это первое посещение пользователем указанного URL. Сервер отвечает, отправляя запрашиваемую страницу, с дополнительным указанием браузеру сохранить файл cookie со следующим содержимым: HTTP:/1.1 200 ok Content-type: text/html SET-cookie: name=value (содержимое страницы). В последствие, это существенно облегчит браузеру загрузку этой страницы, при любом повторном обращении. 3. При следующем обращении к серверу, браузер прикрепит этот, сгенерированный на сервере файл cookie к сформированному запросу, вот так: GET /index.html HTTP/1.1 HOST: www.example.org cookie: name=value Accept:/ Такое изначально направленное на извлечение максимального юзабилити при работе пользователя с веб-приложениями и сервером баз данных взаимодействие может стать причиной утечки приватной и чувствительной информации. Приведем пример использования подмены файла cookies при вредоносных атаках на сервер. Для этого продолжим взаимодействие, которое было показано выше. 4. Сервер отвечает, отправляя запрашиваемую страницу и, возможно, добавив новые значения в файл cookie, после переслав его на сторону пользователя. 5. Предположим, что набор значений, хранимых в файле cookie изменяется путем добавления новых строк SET- cookie: name=newvalue. 6. С момента добавления в файл cookie значения, которое может быть изменено, этот файл становится уязвимым. Дело в том, что значения файлов cookie могут устанавливаться скриптами, написанными на языке JavaScript, встроенными в текст страниц, или аналогичными скриптами, работающими в браузере. В JavaScript для этого используется объект document.cookie. Например, действие скрипта с аргументом document.cookie = "temperature=20" создаст запись cookie под именем «temperature» и присвоит ей значение 20. 7. Перехватив в ходе сеанса обмена данными между приложением и сервером cookie, злоумышленник в списке параметров cookie потенциально может найти возможность для осуществления атаки. Значение изменяется, перехваченный и измененный файл cookie отправляется злоумышленником дальше на сервер. Например, такое изменение неудачного параметра cookie файла позволит злоумышленнику завладеть правами администратора сервера: isAdmin [0] -> [1]. Смысл атаки ***blind-перебором*** – с помощью упорядоченного набора SQL запросов к серверу, основываясь на реакции СУБД на эти запросы, восстановить структуру таблиц с чувствительной информацией (см. alerts в Лекции 5). Оставленные без настройки реакции СУБД на запросы дают очень много информации не только рядовым пользователям, но и злоумышленникам. В общем виде, атака blind-перебором выглядит следующим образом. 1. Выяснение названия и версии СУБД. Это уже может подсказать злоумышленнику приблизительную структуру системных и ключевых таблиц базы данных. 2. Определение одной или нескольких интересных для проникновения таблиц в базе данных. Как правило – это списки пользователей, их паролей. Например, таблицы admins, users, policy, rights и т.д. могут представлять особенный интерес. 3. После выявления интересных таблиц происходит последовательное восстановление метаинформации о структуре таблицы: определение количества столбцов, определение типа данных столбцов и их названия, последовательности их в структуре таблицы. 4. После выявления структуры таблицы, получив права на вставку в нее новых значений, злоумышленник может внести строку со значениями своего пользователя с максимальным доступом к функциям базы данных. Атаки с использованием ***SQL-инъекций*** осуществляются с помощью динамических (встроенных) SQL инструкций, которые могут быть введены на стороне пользователя в незащищенную веб-форму, принимающую SQL параметры, или даже в строку URL, соединяющую пользователя с целевым сервером. По причине своей простоты и эффективности, случаи с SQL инъекциями являются наиболее распространенными среди всех вредоносных атак (по данным сайта OWASP, это около 80% случаев). Приведем пример случая с такой атакой. Предположим, что пользовательское приложение включает в себя функцию аутентификации через html-форму, показанную на рис. 1.  После ввода данных со стороны пользователя, в СУБД отправляется запрос типа: SELECT * FROM users WHERE email = $_POST['email'] AND password = md5($_POST['password']); Если результатом этого запроса является существующая строка с Email и password (хешированным md5), то пользователь успешно проходит аутентификацию на сервере. Зная структуру этого запроса к СУБД злоумышленнику достаточно с помощью динамического SQL заменить неизвестные ему параметры почты и пароля пользователя на условие, которое в случае выполнения им на сервере выведет все значения из целевой таблицы с адресами почты и паролями пользователей. Как правило, это условие инструкции SQL, исполняемое в любом случае, например, для нашего случая xxx@xxx.xxx' OR 1 = 1 LIMIT 1 -- ‘ ]. Учитывая значительное количество атак инъекциями, уже давно были сформированы базовые правила защиты веб приложений и серверов от этого вида воздействия. • настройка параметризованного запроса с плейсхолдерами, то есть запроса с переменными, которые жестко прописаны в скрипте с кодом и не меняются в зависимости от данных; • применение escaping-функций, заложенных в языки программирования, которая заменит потенциально опасные SQL символы на безопасные escape-последовательности. Например, в языке веб-приложений PHP для СУБД MySQL это функция mysql_real_escape_string; • использование хранимых процедур для инкапсуляции всех SQL-запросов. Пользователь лишь передает входные данные, обрабатываются и передаются на сервер они уже по итогам работы процедуры. По своей логике этот способ похож на параметризованный запрос с плейсхолдерами; • использование в коде форм приложения регулярных выражений с целью обнаружения потенциально вредоносного кода и его удаления или изменения перед передачей этого кода в СУБД; • создание и постоянный мониторинг прав доступа на подключение к базе данных. Учетным записям, которые используются для подключения к базе данных, должны предоставляться только необходимые права доступа. Подробно этот элемент безопасности рассмотрен в Лекции 6. • модификация сообщений об ошибках на стороне СУБД. Они не должны раскрывать конфиденциальную информацию. Разумно использовать простые пользовательские сообщения об ошибках, такие как «Извините, возникла техническая ошибка. Служба поддержки уже уведомлена о ней. Повторите попытку позже». **2-ой учебный вопрос: Управление сетевой безопасностью серверов баз данных.** Действия, направленные на мониторинг безопасного состояния серверов баз данных, можно представить в виде чек-листа администратора по безопасности. Ниже перечислены элементы контроля, которые должны регулярно подвергаться мониторингу администратором. • определение и постоянный мониторинг настроек удаленного доступа к серверу баз данных; • настройка и мониторинг контроля доступа на стороне хоста (сервера баз данных); • управление полномочиями на уровне экземпляра сервера базы данных (пользователи, роли, создание баз данных, логин и репликация); • управление полномочиями на уровне баз данных (соединение, создание схем и т. д.); • управление полномочиями на уровне схем баз данных (использование схем, создание объектов внутри схем); • управление полномочиями на уровне таблиц базы данных (выборки, добавление значений, изменение значений и т. д.); • управление полномочиями на уровне столбцов (предоставление и изъятие доступа к столбцам); • RLS (ограниченный доступ к строкам). Большинство перечисленных в чек-листе функций были описаны в материале Лекции 6 и сопутствующих ей практических занятий, поэтому обратим внимание лишь на первые два пункта. Рассмотрим настройки удаленного доступа к серверу на примере СУБД PostgreSQL. Настройки доступа PostgreSQL изменяются при помощи командной консоли, путем изменения параметров соответствующих конфигурационных файлов. Для выполнения поставленной задачи понадобятся конфигурационные файлы postgresql.conf и pg_hba.conf. Конфигурационный файл postgresql.conf используется для базовой настройки удаленного доступа к серверу. Важно отметить, что изменения этого файла возможны в ходе работы сервера, но изменения будут приняты только после его перезагрузки. Ключевые параметры файла: #listen_addresses – адрес или адреса серверов баз данных; #port – номер порта или номера группы портов, открытые для взаимодействия с сервером базы данных; #max_connections – максимально допустимое количество одновременных сеансов работы с сервером; #superuser_reserved_connections – количество сеансов, зарезервированных для суперпользователей (пользователи, имеющие полный доступ ко всем объектам и функциям базы данных); #ssl – параметр, включающий/выключающий использование сертификатов SSL для безопасного шифрованного обмена между сервером и клиентом. При включении этой функции, для обеспечения работы шифрования, необходимо создать файл с сертификатом сервера (server certificate) и приватным ключом сервера (server private key) и разместить их в папке сервера $PGDATA. После указания пути к этим файлам в конфигурационном файле и перезагрузки, заработает SSL шифрование. Конфигурационный файл pg_hba.conf устанавливает условия доступа к серверу баз данных. В этом файле содержатся строки с описанием возможных вариантов установления соединения с сервером. Строка выглядит следующим образом: # /правило/ /имя база или базы данных/ /имя или имена пользователей/ /адрес и порт, доступные для соединения/ /метод соединения/. Рассмотрим варианты параметров строки. Правила соединения могут быть следующие: local, host, hostssl (доступен обмен данными только с настроенным ssl шифрованием). Методы соединения могут быть следующие: trust (без пароля), reject (соединение в любом случае будет отклонено), md5 password (пароль для соединения хеширован md5), ident (идентификация на уровне операционной системы). Ниже приведем пример нескольких строк конфигурационного файла с указанными параметрами. #IPv4 local connections: host all all 127.0.0.1/32 trust Доверять всем пользователям доступ ко всем базам данных по адресу 127.0.0.1 и номеру порта 32.