ПРОБЛЕМЫ БЕЗОПАСНОСТИ НЕРЕЛЯЦИОННЫХ (NOSQL) БАЗ ДАННЫХ

Базы данных NoSQL – это нереляционные базы данных с возможностью масштабирования, оптимизированные для использования моделей данных без единой схемы. Базы данных NoSQL получили широкое распространение, поскольку они упрощают разработку, обеспечивают отказоустойчивость и низкую задержку. Такие базы данных могут использовать различные модели данных, включая столбчатые, документные, графовые данные и хранилища пар «ключ-значение» в памяти. Ресурсы, представленные на этой странице, помогут начать работу с базами данных NoSQL. Базы данных NoSQL отлично подходят для приложений, требующих более высокой масштабируемости и более низкого времени отклика, чем могут обеспечить традиционные реляционные базы данных. В их числе – многие приложения для больших данных, мобильные и интернет- приложения. За счет использования упрощенных структур данных и горизонтального масштабирования базы данных NoSQL, как правило, обеспечивают более низкое время отклика по сравнению с реляционными базами данных и проще масштабируются.

Приведем таблицу некоторых критериев сравнения реляционных и нереляционных баз данных:

Таблица 1.

Сравнение характеристик реляционных и нереляционных баз данных

В обществе IT-специалистов нередко встречается мнение, что нереляционные СУБД безопасны, так как они не используют язык запросов SQL и злоумышленник не может провести на них атаки используя уязвимость SQL-injection. В какой-то степени — с этим поспорить нельзя: нет SQL — значит, нет SQL-инъекций. Но, в системе не применяется SQL-код, это совсем не значит, что она может считаться безопасной. NoSQL закрывает одну возможную уязвимость, при этом открывая множество других, которые позволяют совершать разнообразные вредоносные действия:

• Производить манипуляцию c интерфейсом REST и подделку межсайтовых запросов
• Использовать в параметрах запроса регулярные выражения
• Если на сервере установлена NoSQL-СУБД, выполнять скрипты на сервере
• получать доступ к данным через специальный интерфейс, исправляя запросы к СУБД

Представим возможную архитектуру приложения (наиболее часто применимую) с доступом к базе данных NoSQL. Она может состоять из трех уровней:

• WEB приложение
• Прикладной интерфейс (API) базы данных NoSQL
• NoSQL Система Управления Базами Данных

Рисунок 1. Архитектуры приложения с использованием NoSQL БД

Первый уровень — приложение, которое может быть взломано. Целью злоумышленника может стать место программного кода, где плохо отфильтрованы входные данные. В данном случае может использоваться тот же подход, что и при поиске SQL-инъекций (анализ кода и сообщений об ошибках), только в этом случае при эксплуатации применяются знания работы с JSON, JavaScript или чем-то аналогичным.

Второй уровень — клиентский интерфейс прикладного программирования. Большинство NoSQL-СУБД имеют большой пакет различных библиотек для доступа к данным. Тут возникает еще одна проблема неподдерживаемых библиотек, которые предоставляются с открытым исходным кодом. В самой СУБД обнаружить уязвимость намного сложнее, нежели чем в свободно распространяемой. И даже если не удастся найти какую-либо уязвимость, открывающую доступ к приложениям, построенным на основе этого прикладного интерфейса, можно проанализировать, как именно происходит связь и обмен данными между клиентом и сервером баз данных, используемый протокол и как составляется сессия.

Третий уровень — это уровень СУБД. Как и любое приложение, СУБД может быть подвержена атакам буферного переполнения или иметь уязвимую схему аутентификации. Производить атаки на данном уровне является сложной задачей, потому что сообщество, сформированное вокруг продукта, и сам разработчик СУБД стараются исправлять слабые места при их выявлении. Но большинство программных продуктов поставляются с открытым исходным кодом, а значит, злоумышленник может проанализировать его и, возможно, найти потенциальную “дыру”.

Основные уязвимости NoSQL на примере взлома WEB приложения

• инъекции в регулярных выражениях
• JSON-инъекции
• манипуляции с REST-интерфейсом
• JavaScript-инъекции

Инъекции в регулярных выражениях. Пусть, аутентификация пользователя происходит посредством запроса, который в качестве пароля использует регулярное выражение. При этом переменная passwd (переменная пароля) никак не фильтруется, что открывает возможности для проведения атаки. Таким образом, в качестве имени пользователя можно указать root (предположительное имя пользователя администратора) и регулярное выражение вместо пароля, например, [\s\S]*. В итоге MongoDB выполнит следующий запрос: «db.users.findOne({login: ‘root’, password: /^[\s\S]*/i})», и получится войти на уязвимый сайт под логином root (этот прием напоминает классическую SQL-инъекцию «1′ or 1=1 #«). Защититься от подобной атаки несложно. Во-первых, всегда необходимо проверять входные данные из любых источников (от пользователя, из внешнего файла, из базы данных). Соответственно, основная проблема многих уязвимостей – отсутствие фильтрации вводимых данных. Так же, не рекомендуется использовать регулярные выражения без необходимости.

var regPSWD = new RegExp("^" + passwd, "i");

var loginStr = { login: login, passwd: regPSWD };

Инъекция: password = [\s\S]* (аналог 1′ or 1=1# в SQL)

Итог: db.users.findOne({ login :  ‘root’, password :  /^[\s\S]*/I });

Листинг 1. Пример инъекции в регулярных выражениях

JSON инъекции. Хоть MongoDB и не поддерживает язык запросов SQL, но СУБД не может обойтись без языка запросов. Разработчики MongoDB решили вместо SQL использовать известный текстовый формат обмена данными JSON (BSON). Таким образом, может иметь место разного рода атаки- инъекции (при недостаточной фильтрации данных). Такого вида атаки обычно называют JSON-инъекциями.

var loginStr = eval("({ login: '" + login + "', password: '" +passwd + "' })");

Инъекция: login = root’})// (пароль вводить необязательно)

Итог: ({ login: 'root'})//', password: '' })

db.users.findOne({ login: 'root' });

Листинг 2. Пример JSON-инъекции

Вышеприведенный код преобразует текстовое представление объекта JavaScript (запроса к MongoDB) в объект. После передачи этого объекта на сервер баз данных происходит аутентификация пользователя. В приведенном листинге есть весьма слабое место — не контролируются входные данные, поэтому возможно сформировать практически любой запрос к базе данных! Например, можно указать имя пользователя «root’})//» (пароль вводить необязательно).

Манипуляции с REST-интерфейсом. В СУБД  MongoDB входит простой REST-интерфейс, который позволяет получить доступ к данным из базы данных. Для формирования REST-запроса к базе данных используется URL следующего вида (в общем случае):

http://127.0.0.1:порт/базаданных/коллекция/?filter_поле=значение

Переход по такому адресу формирует REST-запрос, игнорируя при этом после символа «#» все данные. Когда REST-запрос выполнен, специальный скрипт формирует HTTP-запрос к серверу и ожидает ответ (результат) в формате JSON. К примеру, запрос информации о пользователе с правами администратора в базе данных может быть таким: http://127.0.0.1:порт/users/?login=root&password=passwd. Всё бы хорошо, но в функции обработки есть ошибка, проявляющая себя при обработке символа «#». Если попробовать войти с именем «root#», то аутентификация пройдет успешно. Проблема, обусловленная формированием следующего URL: http://localhost:порт/users/? login=root#& password=. состоит в том, что параметр password был проигнорирован и аутентификация проходила посредством запроса http://localhost:порт /users/?login=root.

http://127.0.0.1:28017/users/?login=root&password=p@ssw0rd

Инъекция: login = root#

Итог: http://127.0.0.1/users/?login=root#&password=root -> http://localhost/users/?login=root

Листинг 3. Пример манипуляций с REST-интерфейсом

JavaScript инъекции. Создание хранимых процедур – функционал, который имеют большинство реляционных СУБД. MongoDB имеет аналогичный функционал, а именно серверный JavaScript. По факту, можно исполнить почти любой код на сервере баз данных. Это позволяет писать приложения с очень сложной логикой для обработки различных данных, но это делает потенциальное приложение более уязвимым.

Пусть на этот раз аутентификация происходит благодаря вызову функции eval на серверной стороне (сервер базы данных):

var code = "function () { return db.users.findOne ({ login: '" + login + "', passwd: '" + password + "' }); }“;      db.eval(code);

Инъекция: login = '}), db.users.insert({login: 'testlogin', passwd: 'testpasswd'}), 1 }//

Итог: Успешный вход в систему и новый пользователь в базе

Листинг 3. Пример JavaScript инъекции

Заключение. В скором будущем применение NoSQL баз данных займет сравнительно большую долю высоконагруженных приложений. Но безопасность современных NoSQL-СУБД оставляет желать лучшего. Если в мире реляционных баз данных существует стандартизированный язык запросов — SQL, то при использовании нереляционных баз данных, каждый реализует произвольный язык запросов: XQuery, JSON, REST-интерфейсы. Поэтому, и возможных уязвимостей намного больше. Если для обеспечения безопасности реляционных баз данных уже было проведено много исследований и существует вполне устоявшийся порядок действий, то для нереляционных подходов на данный момент сложно найти какой-либо универсальный способ обеспечения конфиденциальности, доступности и целостности данных.

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

1. Мартин Фаулер. Новая методология разработки нереляционных баз данных, 2013. – 254 с.
2. Смирнов С.Н. Безопасность систем баз данных. Издательство: Гелиос АРВ, 2007. – 511 с.