CC BY
127В современных условиях, при недостатке финансирования автотранспортных предприятий, важным является эффективное использование производственно -технической базы. Ведь это напрямую влияет на состояние подвижного состава. Проведение всего перечня операций ТО и Р, наличие современного оборудования, позволят долгие годы поддерживать исправное техническое состояние транспортных средств предприятия.
Литература
1. Напольский Г. МТехнологическое проектирование автотранспортных предприятий и станций технического обслуживания: учебник для вузов. М.: Транспорт, 1985. 231 с.
2. Юркова Т. И., Юрков C. В. Экономика предприятия / Т. И. Юркова, С. В. Юрков. ГАЦМиЗ. Красноярск, 2006. 116 с.
NOSQL — ИНЪЕКЦИИ НА ПРИМЕРЕ НЕРЕЛЯЦИОННОЙ
СУБД MONGODB Фримучков А. Н.
Фримучков Андрей Николаевич /Frimuchkov Andrey Nikolaevich - студент, факультет кибернетики, Московский технологический университет, г. Москва
Аннотация: в статье рассматриваются вопросы уязвимости нереляционных баз данных, в том числе MongoDB. В настоящее время считается, что нереляционные базы данных, в сравнении с классическими реляционными, являются более безопасными по причине отсутствия SQL и, соответственно, связанных с ним инъекций. Однако нереляционные базы данных имеют целый ряд специфических уязвимостей, как в них самих, так и в системе управления, что делает нереляционные базы данных не такими безопасными, как кажется на первый взгляд. Ключевые слова: информационная безопасность, базы данных, нереляционные СУБД.
Введение
Понятие NoSQL (Not Only SQL или No SQL) получило известность с 2009 года. Именно тогда развитие web-технологий и социальных сервисов дало толчок множеству новых подходов к хранению и обработке данных. Разработчики подобных приложений столкнулись с задачами, для которых традиционные реляционные СУБД оказались либо слишком дороги, либо недостаточно производительны. Кроме того, популяризаторами отказа от универсальных «комбайнов» (реляционные СУБД -РСУБД) в пользу специализированных решений стали молодые проекты и те, кому приходится работать в сценариях так называемых Big Data [1].
Уязвимости NoSQL
Логично будет предположить, что нереляционные СУБД безопасны, потому что в них отсутствуют SQL-запросы и, соответственно, отсутствует возможность провести SQL-инъекцию. Отчасти это так степени, но если в запросе отсутствует SQL-код, это еще не говорит, система безопасна. NoSQL закрывает лишь уязвимости типа SQL-инъекции, при этом оставляя множество других.
Обычно она состоит из трех уровней [3]:
• приложение;
• API базы данных NoSQL;
• NoSQL-СУБД.
Каждый их этих уровней потенциально уязвим. Начнем с нижнего, то есть самой СУБД. Как и любое приложение, СУБД может быть подвержена атакам переполнения буфера или иметь уязвимую схему аутентификации. Атаковать этот уровень сложно, потому что за подобными уязвимостями следят как сообщество, так и разработчики.
Следующий уровень — API. Большинство NoSQL-СУБД имеют огромное количество библиотек для организации доступа к данным. Большинство таких проектов имеют открытый код, но часть из них уже не поддерживаются, поэтому вероятность обнаружить уязвимость на этом уровне гораздо выше.
Ну и наконец, верхний уровень — атакуемое. Здесь нужно попытаться найти места, в которых разработчик забыл проверить входные данные. В данном случае используется тот же подход, что и при поиске SQL-инъекций, однако в данной ситуации придется разбираться с JSON, JavaScript или чем-то подобным.
Уязвимости нижнего уровня NoSQL
Рассмотрим уязвимости (или слабые места) на основе анализа нескольких версий MongoDB [3]:
1. Уязвимое место в системе аутентификации. По-умолчанию БД устанавливается без пароля. Создатели MongoDB предполагают, что БД запускается в полностью доверенном окружении.
2. Уязвимое место в системе авторизации. Любой созданный пользователь по-умолчанию имеет доступ на чтение всей базы данных, то есть он имеет доступ ко всему, что у нас имеется.
3. Уязвимое место в системе авторизации администратора. Пользователь с доступом к базе данных Admin имеет права на чтение/запись откуда/куда угодно. А т.к. по-умолчанию нет пароля, то мы имеем доступ везде.
4. Нешифрованный текст. Все данные передаются в открытом виде, то есть они могут быть перехвачены любой MITM—атакой.
5. Доступ с любых интерфейсов. По-умолчанию, БД доступна со всех интерфейсов, что является потенциальной угрозой, т.к. не ко всем интерфейсам есть доверие.
Инъекции в регулярных выражениях
MongoDB, как и многие другие NoSQL-СУБД, предоставляет возможность выполнять поиск при помощи регулярных выражений. Это очень удобный инструмент, однако он представляет собой серьёзную потенциальную угрозу [3].
Для осуществления поиска при помощи регулярных выражений используется оператор $regex. Запрос «верни мне всех пользователей, логин которых начинается с «user»» представлен на рисунке 1.
db.users.fmd({ login: { $regex: t1Aiiser"} })
Рис. 1. Пример запроса с $regex Обработка самого запроса представлена на рисунке 2.
var regexpPwd= new RegExp("A" + password, "i"); var loginParam= { login: login, password: regexpPwd }
Рис. 2. Выполнение запроса с $regex
Для выполнения инъекции достаточно передать вместо пароля строку «[\s\S]*». Этот приём похож на классическое для SQL «1' or 1=1 --». Решение крайне тривиальное - нужно проверять входные данные.
JSON-инъекции
В MongoDB нет SQL-синтаксиса, однако СУБД не может обойтись без языка запросов, поэтому разработчики MongoDB решили использовать вместо SQL JSON. Поэтому можно попробовать осуществить разные атаки-инъекции (конечно, если нет фильтрации входных данных). Такие атаки обычно называют JSON-инъекциями [2]. Пример самого «небезопасного» кода можно увидеть на рисунке 3.
var loginParam= eval("({ login:+ login + password:'" + password+})");
Рис. 3. Пример небезопасной обработки JSON
Первое, что бросается в глаза это не возможность JSON-иньекции, а использование функции eval. Эта функция выполняет код, которые предан в аргументе, поэтому использовать её не рекомендуется.
Но вернёмся к JSON-иньекции, чтобы её выполнить достаточно передать в логин строку «root'})//», что и было сделано на рисунке 4.
({ login: 'root'})//', password: "}) db.users.findQne({ login: 'root'})
Рис. 4. Эксплуатация уязвимости при обработке JSON Манипуляции с REST-интерфейсом
MongoDB предоставляет REST-интерфейс, который позволяет получить доступ к данным без возможности записи. Кроме того, существует проект под названием Sleepy Mongoose, который реализует полную поддержку REST. Пример такого запроса на рисунке 5.
var qry = "/rest/users/?login-' + login + "& password=" +password: var hash = qry.indexOfi["#"); if (hash >-1) {
qry = qry.substring(0, hash);
}
Рис. 5. Пример запроса через REST-интерфейс
Если мы введём имя пользователя root#, то войдём от имени root, т.к. всё что после # будет проигнорировано. Запрос, конечно же, надуманный и в реальном приложении такое встретить не получится, однако, в том или ином виде подобная уязвимость может быть встречена. Выдох один — фильтрация получаемых данных.
JavaScript-инъекции
Большинство современных реляционных СУБД позволяют создавать хранимые процедуры на сервере. У MongoDB имеются аналогичные возможности, среди которых присутствует серверный JavaScript. Это позволяет исполнять почти любой код на сервере БД. С одной стороны, это даёт возможность писать алгоритмы обработки данных, но с другой — делает приложение более уязвимым.
Области применения JavaScript в MongoDB:
1. Запросы с оператором $where.
2. Команда db.eval.
3. Функции для сохранения в базе данных. Для этого используется специальная системная коллекция system.js.
4. Map/Reduce. Это - программный фреймворк, разработанный компанией Google для параллельных вычислений над большими объемами данных. Заключение
На уровне самой БД при настройках по-умолчанию реализации NoSQL (а именно — MongoDB) существенно проигрывают классических РСУБД. Однако, справедливо было бы заметить, что настройки по-умолчанию не используются на боевых серверах, поэтому, в большинстве случаев, если уязвимость есть только при настройках по-умолчанию, то в серьёзных проектах её не будет. И, всё же, это минус в копилку NoSQL.
А вот на уровне приложения ситуация обстоит гораздо лучше. Большинство уязвимостей основаны на очевидных ошибках в коде и существуют только в примерах, а на практике встретить их практически не представляется возможным.
Литература
1. СУБД NoSQL - сильные и слабые стороны. [Электронный ресурс]. Режим доступа: http://www.jetinfo.ru/stati/silnye-i-slabye-storony-nosql/ (дата обращения: 12.11.2016).
2. Азбука NoSQL-инъекций. [Электронный ресурс]. Режим доступа: https://habrahabr.ru/company/xakep/blog/143909/ (дата обращения: 12.11.2016).
3. Mongodb - Security Weaknesses in a typical NoSQL database. [Electronic resource]. URL: https://www.trustwave.com/Resources/SpiderLabs-Blog/Mongodb—Security-Weaknesses-in-a-typical-NoSQL-database/ (date of access: 12.11.2016).
