Я читал свою надежную книгу О'Рейли и наткнулся на отрывок о том, как Монго по своей природе избегает болота ошибок, вызванных SQL-инъекциями.
В моей кишке, я думаю, я это понимаю. Если неанитированные vars передаются в запросы, они не могут вырваться из структуры документа, ориентированной на запрос, с UNION, JOIN, запрошенными комментариями и т.д.
Как MongoDB избегает беспорядка SQL-инъекций? Является ли это просто по синтаксису этого запроса?
MongoDB избегает потенциальных проблем, не анализируя.
Любой API, где угодно, который включает в себя кодирование пользовательских данных в форматированном тексте, который получает разобранный, имеет потенциал для вызывающего и вызываемого, чтобы не согласиться с тем, как этот текст следует разбирать. Эти разногласия могут быть проблемами безопасности, когда данные неверно истолковываются как метаданные. Это верно, если вы говорите о строках формата printf, включая пользовательский контент в HTML или генерируете SQL.
Так как MongoDB не анализирует структурированный текст, чтобы выяснить, что делать, нет никакой возможности неверно интерпретировать ввод пользователя в качестве инструкций и, следовательно, нет возможного дыра в безопасности.
Кстати, совет по избеганию API-интерфейсов, требующих разбора, - это пункт 5 в http://cr.yp.to/qmail/guarantee.html. Если вы заинтересованы в написании безопасного программного обеспечения, другие 6 предложений тоже стоит посмотреть.
Подводя итог документации MongoDB
BSON
Как клиентская программа собирает запрос в MongoDB, он создает Объект BSON, а не строка. Таким образом, традиционные атаки SQL-инъекций не проблема.
Однако MongoDB не защищен от инъекционных атак. Как отмечено в той же документации, атаки на инъекции по-прежнему возможны, поскольку операции MongoDB позволяют выполнять произвольные выражения JavaScript непосредственно на сервере. Документация подробно рассматривается ниже:
С PHP mongoDB может стать уязвимым для инъекции без SQL:
http://www.idontplaydarts.com/2010/07/mongodb-is-vulnerable-to-sql-injection-in-php-at-least/
База данных не может анализировать содержимое, но есть другие уязвимые области кода.
Чтобы защитить от SQL-инъекции, клиенты могут использовать API-интерфейсы MongoDB. Таким образом, все входные данные являются простыми значениями - команды не могут быть введены. Пример Java:
collection.find(Filters.eq("key", "input value"))
Недостатком является то, что вы не можете легко проверить свой фильтр. Вы не можете скопировать его в оболочку Mongo и проверить его. Особенно проблематично с более крупными, более сложными фильтрами/запросами.
НО!!! там также API, чтобы не использовать API-фильтр, позволяющий анализировать любой json-фильтр. Пример Java ниже:
collection.find(BasicDBObject.parse("{key: "input value"}"));
Это хорошо, потому что вы можете скопировать фильтр непосредственно в оболочку MongoDB, чтобы проверить его.
НО!!! (последнее, но, я обещаю), это склонно к инъекции NoSql. Пример Java, где входное значение {$gt: ""}.
collection.find(BasicDBObject.parse("{key: {$gt: ""}}"));
В этом последнем примере все возвращается, хотя мы имели в виду только для возврата конкретных записей.
Смотрите здесь более подробное объяснение по SQL-инъекции при непосредственном использовании фильтров.
Последнее. Я думаю, что есть способ использовать оба необработанных фильтра и по-прежнему защищать от SQL-инъекций. Например, в Java мы можем использовать заданные параметрами Jongo.