How Does Mongodb Avoid the SQL Injection Mess

How does MongoDB avoid the SQL injection mess?

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.

How dangerous is MongoDB's $where operator?

Your RBAC set up would govern access to the HTTP service. Having the mongo find method in function won't allow anything but find/read operations to that particular collection. Nothing precludes the user from specifying an expensive query. However, a query spanning a single collection is unlikely to be super expensive and you are limiting the results to 10.

What does ${data} mean in SQL?

${data} is not part of the SQL language.

It looks like string interpolation, which is almost certainly vulnerable to sql injection.

I say "almost" because some ORM tools will use interpolation hooks to do correct query parameterization... but even these would tend to look at individual values, and not the entire WHERE clause. It's also possible the where clause provided for interpolation includes valid placeholders for parameterized queries, and there is additional code we don't see to handle this correctly. But it doesn't seem very likely.

Is nosql injection possible for Ruby on Rails with Mongoid?

Common operations including queries and inserts/updates in Mongoid sanitize their inputs, thus most times one does not need to worry about "nosql injection".

However, there are methods that pass commands directly to the database, and in those cases it is important to carefully consider whether unsanitized user input can end up as a database command. For example, if Post is a Mongoid model, one can run the following command to create an infinite loop in a MongoDB server:

Post.all.map_reduce('function(){while(true);}','function(){}').out(inline:1).count

Another example is Database#command method provided by the driver to run arbitrary database commands: http://api.mongodb.com/ruby/current/Mongo/Database.html#command-instance_method. If an application places user input into parameters given to this method, this creates potential for "nosql injection".

Note also that it is not necessary to pass an unexpected command to the database - sometimes unexpected data is sufficient. See, for example, https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS. Assuming the Post model has a body field, passing an arbitrary regular expression from the user could be problematic:

# This might take a while
Post.where('body' => {'$regex' => '((a|a?|a*)*)*$'}).count

Security, javascript-injection in mongoengine

Mongoengine escaped string, so is no possibility for javaScript injection.
https://github.com/MongoEngine/mongoengine/search?utf8=%E2%9C%93&q=escape

How Efficient is Mongo DB ISOLATION

I came across a document that Mongo DB maintains a global write lock

That's old information, MongoDB is now on a database level lock, maybe sometime in the future collection, however, that has been put back in favour of concurrency.

wanted to know how efficient it is to support "ISOLATION" of "ACID" as of SQL database.

First thing first, MongoDB IS NOT AN ACID DATABASE. If you want ACID you should go with an ACID compliant database. Don't try and make a database do what it isn't designed to do.

As for actual isolation, currently MongoDB has isolation on a single document level with atomic operations such as $inc, $set, $unset and all those others. Isolation does not occur on multiple documents, there is an $isolated ( http://docs.mongodb.org/manual/reference/operator/isolated/ ) operator but it is highly recommened not to use it, plus it isn't supported on sharded collections.

There is also a documentation page on providing isolation levels: http://docs.mongodb.org/manual/tutorial/isolate-sequence-of-operations/ but only findAndModify and indexing can provide some element of isolation whereby other queries will not interferer.

Fundamentally, even if it had atomic operations on multiple documents, MongoDB cannot normally support isolation across many documents, this is due to one of its main concurrency features, the ability to subside out of memory operations for ones in memory.

And so I come back to my original point, if you want ACID go to a ACID tech.

NoSql Injection in Python

There are a couple of concerns with injection in MongoDB:

• $where JS injection - Building JavaScript functions from user input can result in a query that can behave differently to what you expect. JavaScript functions in general are not a responsible method to program MongoDB queries and it is highly recommended to not use them unless absolutely needed.
• Operator injection - If you allow users to build (from the front) a $or or something they could easily manipulate this ability to change your queries. This of course does not apply if you just take data from a set of text fields and manually build a $or from that data.
• JSON injection - Quite a few people recently have been trying to convert a full JSON document sent (saw this first in JAVA, ironically) from some client side source into a document for insertion into MongoDB. I shouldn't need to even go into why this is bad. A JSON value for a field is fine since, of course, MongoDB is BSON.

As @Burhan stated injection comes from none sanitized input. Fortunately for MongoDB it has object orientated querying.

The problem with SQL injection comes from the word "SQL". SQL is a querying language built up of strings. On the other hand MongoDB actually uses a BSON document to specify a query (an Object). If you keep to the basic common sense rules I gave you above you should never have a problem with an attack vector like:

SELECT * FROM tbl_user WHERE ='';DROP TABLE;

Also MongoDB only supports one operation per command atm (without using eval, don't ever do that though) so that wouldn't work anyway...

I should add that this does not apply to data validation only injection.

Avoid sql injection in Devexpress Grid where\filter condidtion

Not the way it's designed. Or at least not without carefully parsing the statement and then leveraging parameterized values and/or positively validating the components. And doing that is much more complex and prone to error than just passing the components.

In your current design, it's trivial to inject SQL into the where or order by. You should break this down into its components, pass those through and validate them at the backend. So, rather than passing ColomnA like N'ABC' (sic) you should pass ColomnA (sic) and ABC seperately, and use parameterized queries for the values (bind them).

In the second case, many databases will not allow parameterizing order by values, so you should be sure to use positive validation in that case.

---

Related Topics