73

I was reading my trusty O'Reilly book and came across a passage about how Mongo, by nature, avoids the morass of SQL injection-like flaws.

In my gut, I think I understand this. If unsanitized vars are passed into queries, they can't break out of the document-oriented query structure with a UNION, JOIN, query turned comment, etc.

How does MongoDB avoid the SQL injection mess? Is it just by nature of this query syntax?

Improve this question
1
  • I don't think anyone has commented on the potential dangers of the use of parsing middlewares (like body-parser with the nodejs express lib, for example). If you're parsing post parameters as JSON (which is fairly common) and then passing those parameters (or properties of those parameters) directly into a mongo query, then an attacker can insert a js object where you expected a string/number (e.g. they could pass {$gt:-1} and view all the documents in your collection) Commented Jan 5, 2017 at 1:11

5 Answers 5

Reset to default
49

MongoDB avoids the potential for problems by not parsing.

Any API, anywhere, that involves encoding user data in formatted text that gets parsed has the potential for the caller and callee to disagree on how that text should be parsed. These disagreements can be security issues when data is misinterpreted as metadata. This is true whether you're talking about printf format strings, including user generated content in HTML, or generating SQL.

Since MongoDB doesn't parse structured text to figure out what to do, there is no possibility of misinterpreting user input as instructions, and hence no possible security hole.

Incidentally the advice of avoiding APIs that require parsing is item 5 in http://cr.yp.to/qmail/guarantee.html. If you're interested in writing secure software, the other 6 suggestions are worth looking at as well.

Update (2018): The original answer as I gave it remains true to the best of my knowledge. From the point of what is sent to MongoDB to what is sent back, there is no SQL injection attack. The injection attacks that I'm aware of happen outside of MongoDB and are actually problems in how external languages and libraries set up the data structure that will be passed to MongoDB. Furthermore the location of the vulnerability is in how data is parsed on the way to becoming a data structure. Therefore the original answer accurately describes both how to avoid injection attacks, and what puts you at risk of them.

But this accuracy is cold comfort to a programmer who is hit by injection attacks from defects that were not obvious in their own code. Few of us distinguish between the external tool and all the layers between our code and that external tool. And the fact remains that it requires vigilance on our part to anticipate and close off injection attacks. With all tools. And this will remain the case for the foreseeable future.

Improve this answer
Sign up to request clarification or add additional context in comments.

13 Comments

note that this answer (though helpful) is incorrect - the other two answers provide a case where "SQL-injection-like" attack can be done. It's a wild world out there and you need to properly sanitize your input data. ;)
@johndodo Please note that my answer appeared before the PHP vulnerability was discovered. Please also note that my answer remains correct for every language other than PHP, and that the cause of the hole is PHP's volunteering to parse data in a surprising way.
true - I didn't mean to oppose you, but many people find answers through Google so I thought I'd set the record straight. Also, while I am not that familiar with other web languages, some HTML inputs post values as arrays so I would say the issue is not PHP-only. General rule still applies: always validate user input.
There's more to this issue. MongoDB, by default, allows execution of arbitrary JavaScript. From their docs: "You must exercise care in these cases to prevent users from submitting malicious JavaScript.". You can disable JS support, but that also disables JS support for server-side scripting. OWASP talks about this here
It's a shame that this answer is upvoted so high. MongoDB No-SQL attacks have been demonstrated in several languages and this answer gives a false sense of security.
|
29

To summarize the MongoDB documentation

BSON

As a client program assembles a query in MongoDB, it builds a BSON object, not a string. Thus traditional SQL injection attacks are not a problem.

However, MongoDB is not immune from injection attacks. As noted in the same documentation, injection attacks are still possible as MongoDB operations allow arbitrary JavaScript expressions to be executed directly on the server. The documentation goes into this in detail:

http://docs.mongodb.org/manual/faq/developers/#javascript

Improve this answer

3 Comments

Not the whole story. Just below your quote, the same documentation explains how to execute arbitrary JavaScript against Mongo. This behavior is enabled by default, and the documentation says: "You must exercise care in these cases to prevent users from submitting malicious JavaScript.". You can disable JS support, but that also disables JS support for server-side scripting. OWASP talks about this here
It goes without saying that SQL injection attacks are not a problem, MongoDB does not understand SQL. However, No-SQL injection attacks are still possible with MongoDB.
The question specifically asks about SQL-injection attacks, but I agree that the risks related to no-sql should be made clear. I have updated the answer.
18

With PHP mongoDB can become vulnerable to No-SQL injection:

http://www.idontplaydarts.com/2010/07/mongodb-is-vulnerable-to-sql-injection-in-php-at-least/

http://www.php.net/manual/en/mongo.security.php

Improve this answer

2 Comments

I just saw that. Note that the problem there is fundamentally that PHP helpfully parses user input, which allows the user to cause data and metadata to be confused in a way that should not have been possible.
@James So placing a string cast before the variables will fix this problem...Is there anything else I should be worried about, or is that the only fix?
6

To protect against SQL injection, clients can use MongoDB's language APIs. This way, all the input is simple value - commands cannot be injected. A Java example:

collection.find(Filters.eq("key", "input value"))

The drawback is that you cannot easily test your filter. You cannot copy it to Mongo's shell and test it. Especially problematic with bigger, more complex filters/queries.

BUT!!! there's also an API to not use the filter's API - enabling to parse any json filter. Java example below:

collection.find(BasicDBObject.parse("{key: "input value"}"));

This is nice because you can copy the filter directly to the MongoDB shell to test it out.

BUT!!! (last but, I promise) this is prone to NoSql injection. Java example, where the input value is {$gt: ""}.

collection.find(BasicDBObject.parse("{key: {$gt: ""}}"));

In this last example, everything is returned, even though we meant only for the specific records to return.

See here a more thorough explanation on SQL injection when using the filters directly.

One last thing. I think there's a way to use both raw filters and still protect against SQL injection. For example, in Java, we can use Jongo's parameterized queries.

Improve this answer

Comments

4

The database might not parse the content but there are other areas of the code that are vulnerable.

https://www.owasp.org/index.php/Testing_for_NoSQL_injection

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.