БЕЗОПАСНОСТЬ NOSQL БАЗ ДАННЫХ

Введение

База данных – являются хранилищами информации для большинства  современных приложений. Атаки на хранилища информации несут в себе наибольшую опасность для организаций и предприятий. В связи с этим, вопросы защиты данных являются критическими при обеспечении безопасности. Не реляционные базы данных, ставшие широко использоваться не так давно,  отличаются от реляционных по модели данных, способу выборки информации, предъявляемыми требованиями к целостности хранимых данных.

Но сохраняется ли безопасность информации в не реляционных (NoSql) базах данных?

Цель

Целью данной научной работы является поиск уязвимых мест в безопасности не реляционных (NoSQL) баз данных. В данной работе будут рассмотрены обеспечение конфиденциальности, целостности и доступности информации (CIA) в NoSQL базах данных и продемонстрированы самые известные уязвимости на примере популярной БД MongoDB.

Теоретические сведения

Существуют следующие типы NoSQL баз данных:

1. Базы данных на основе документов.

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

2.Базы данных на основе графов.

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

3. Хранилище «ключ-значение».

Хранилища ключ-значение – это самые простые базы данных NoSQL. Каждый элемент хранится в базе в виде пары: имя атрибута (или «ключ») вместе со своим значением.

4.Колоночные базы данных.

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

Основные характеристики NoSQL баз данных:

1. В таких базах данных не используется ANSI SQL DML.
2. NoSQL базы данных являются неструктурированными. Хранят большие объемы денормализованных данных. Такие базы не накладывают ограничения на типы хранимых данных.
3. NoSQL базы данных позволяют представить данные в виде агрегатов (aggregates).
4. Для хранения данных можно использовать облачные хранилища.

Уязвимости NoSQL баз данных

Хранение данных считается безопасным, если БД обеспечивает конфиденциальность, целостность и доступность (CIA). Реляционные базы данных обеспечивают эти функции, предоставляя своим клиентам следующие опции:

• Шифрование данных при хранении, передачи и архивации
• Проверка данных пользователя
• Контроль доступа на основе ролей
• Многофакторная авторизация
• Аудит активности и отчетность
• Мониторинг трафика и защита базы данных от нежелательной активности
• Контроль защищенности рабочего окружения продуктивных СУБД
• Маскировка критичных данных в тестовых средах
• Управление доступом к полю или строке

К тому же реляционные базы данных соответствуют требованиям ACID (атомарность, единообразность, изолированность и надежность)

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

В NoSQL базах данных отсутствуют функционал, обеспечивающий конфиденциальность и целостность данных. Данные в базах такого типа являются неструктурированными, следовательно, доступ к полям и строкам будут иметь абсолютно все пользователи. Это может привести к дублированию данных и затруднить поддержание последовательности данных.

Транзакции в NoSQL базах записываются не сразу. Возникает возможность пересечения транзакций.

К типичным уязвимостям NoSQL баз данных относят:

• Переполнение буфера
• Превышение привилегий
• Хранение информации в незашифрованном виде
• Лазейки системы идентификации / аутентификации
• API. Доступ к NoSQL-СУБД с помощью библиотек. Часто библиотеки имеют открытый исходный код.

Исследуем уязвимости на примере MongoDB – популярной NoSQL БД:

• Уязвимое место в системе аутентификации.
  
  По умолчанию MongoDB устанавливается без пароля. Любой пользователь, имеющий доступ к серверу, автоматически получает доступ и к самой БД. 

Рисунок 1. Пример подключения к MongoDB

• Уязвимость, связанная с контролем доступа
• Уязвимость, связанная с передачей данных в открытом виде
• Уязвимость, связанная с возможность проведения NoSQL-инъекций

Отсутствие возможности выполнение SQL запроса, предотвращает попытки проведения SQL –инъекций, но не является гарантией безопасности.

Инъекции при помощи регулярных выражений

var regPwd = new RegExp("^" + pass, "i");

var loginF = { login: login, password: regPwd };

Если вместо пароля, с клиента передать следующую строку  [\s\S]*, то при отсутствии валидации данных, злоумышленник успешно пройдет аутентификацию.

JSON Injection

Разработчики MongoDB используют вместо языка SQL JSON или, если сказать точнее, BSON.  Передадим с клиента следующую строку: “root'})//”. Если входные данные не фильтруются – произошла так называемая JSON-инъекция. Мы синтетически завершили запрос.

Например:

Уязвимая функция авторизации на JS выглядит следующим образом:

var login = eval("({ login: '" + userLogin + "', password: '" + pass + "' })");

В MongoDB запрос будет иметь следующий вид:

db.users.findOne({ login: 'root'})//', password: ''pass })

вместо

db.users.findOne({ login: 'root', password: 'pass' })

При выполнении такого запроса становится не важно, какой был отправлен пароль с клиента.

Вывод

Если ключевыми требованиями организации к БД являются масштабируемость и доступность, то система NoSQL может быть правильным выбором для определенных датасетов. Архитекторам систем следует тщательно рассматривать свои требования к безопасности, конфиденциальности и целостности перед выбором базы данных NoSQL. Отсутствие в NoSQL функций безопасности, а именно, поддержка аутентификации или авторизации, означает, что конфиденциальные данные лучше всего хранить в стандартных RDBMS.

Список литературы:

1. A. Lane, "No SQL and No Security", blog, 9 Aug. 2011.
2. "Imperva Web Application Attack Report", 4th ed., Imperva, 2013.