Телефон: +7 (383)-202-16-86

Статья опубликована в рамках: XLVI Международной научно-практической конференции «Научное сообщество студентов: МЕЖДИСЦИПЛИНАРНЫЕ ИССЛЕДОВАНИЯ» (Россия, г. Новосибирск, 07 июня 2018 г.)

Наука: Информационные технологии

Скачать книгу(-и): Сборник статей конференции

Библиографическое описание:
Агеев Н.О., Агеева А.И. ПРОБЛЕМЫ БЕЗОПАСНОСТИ НЕРЕЛЯЦИОННЫХ (NOSQL) БАЗ ДАННЫХ // Научное сообщество студентов: МЕЖДИСЦИПЛИНАРНЫЕ ИССЛЕДОВАНИЯ: сб. ст. по мат. XLVI междунар. студ. науч.-практ. конф. № 11(46). URL: https://sibac.info/archive/meghdis/11(46).pdf (дата обращения: 31.03.2020)
Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
У данной статьи нет
дипломов

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

Агеев Николай Олегович

студент 4 курса института информатики, математики и электроники Самарского университета,

РФ, г. Самара

Агеева Ангелина Игоревна

студент 4 курса института информатики, математики и электроники Самарского университета,

РФ, г. Самара

Научный руководитель Додонов Михаил Витальевич

доцент кафедры программных систем Самарского университета,

РФ, г. Самара

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

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

Таблица 1.

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

 

Реляционные базы данных

Базы данных NoSQL

Модель данных

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

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

Свойства ACID

Традиционные СУРБД поддерживают набор свойств реляционной базы данных, обозначаемый как ACID: атомарность, непротиворечивость, изолированность и надежность. Атомарность означает «все или ничего»: транзакция выполняется полностью или не выполняется вообще. Непротиворечивость значит, что сразу по завершении транзакции данные должны соответствовать схеме базы данных. Изолированность требует, чтобы параллельные транзакции выполнялись отдельно друг от друга. Надежность подразумевает способность восстанавливаться после непредвиденного сбоя в системе или перебоя в подаче питания до последнего сохраненного состояния.

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

Производительность

Производительность главным образом зависит от дисковой подсистемы. Для обеспечения максимальной производительности требуется оптимизация запросов, индексов и структуры таблицы.

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

Масштабирование

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

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

API

Запросы на хранение и получение данных составляются на языке SQL. Их анализируют и выполняют СУРБД.

Объектно-ориентированные API позволяют разработчикам приложений просто выполнять запись и извлечение структур данных, размещенных в памяти. Ключи секций позволяют приложениям осуществлять поиск пар «ключ-значение», наборов столбцов или частично структурированных документов, содержащих серийные объекты и атрибуты приложений.

Инструменты

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

Базы данных NoSQL обычно содержат инструменты для управления кластерами и масштабированием. Приложения являются основным интерфейсом для работы с базовыми данными.

 

В обществе 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 с.
Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
У данной статьи нет
дипломов

Оставить комментарий

Уважаемые коллеги, издательство СибАК с 30 марта по 5 апреля работает в обычном режиме