Mongodb injection attacks using the Java / Scala drivers
1,243 views
Skip to first unread message
Amit
Mar 27, 2012, 6:07:17 AM3/27/12
to mongodb-user
I will be using mongodb with a Java middleware layer that interacts
with the db. I wanted to enumerate the possible list of injection
attacks (similar to SQL injection and code injection).
I realize that mongodb Java driver also accepts "raw" queries in
javascript, which seems to be a good point of injection attacks. Apart
from this, would there be any other venues of XSS, noSQL injection
attacks?
I am fairly new to the mongodb Java API, so I probably missed several
weak points.
with the db. I wanted to enumerate the possible list of injection
attacks (similar to SQL injection and code injection).
I realize that mongodb Java driver also accepts "raw" queries in
javascript, which seems to be a good point of injection attacks. Apart
from this, would there be any other venues of XSS, noSQL injection
attacks?
I am fairly new to the mongodb Java API, so I probably missed several
weak points.
Sam Millman
Mar 27, 2012, 6:59:23 AM3/27/12
to mongod...@googlegroups.com
The reason why SQL is so open to injection is due to being formed from strings.
Mongo queries are not formed from strings as such they are almost inheritantly immune to most forms of injection. The only thing I can think about it automatic variable assignment being able to have a knock on effect but that's kinda common sense witin the language itself really.
Mongo queries are not formed from strings as such they are almost inheritantly immune to most forms of injection. The only thing I can think about it automatic variable assignment being able to have a knock on effect but that's kinda common sense witin the language itself really.
--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
Scott Hernandez
Mar 27, 2012, 8:39:09 AM3/27/12
to mongod...@googlegroups.com
On Tue, Mar 27, 2012 at 6:07 AM, Amit <amita...@gmail.com> wrote:
> I will be using mongodb with a Java middleware layer that interacts
> with the db. I wanted to enumerate the possible list of injection
> attacks (similar to SQL injection and code injection).
>
> I realize that mongodb Java driver also accepts "raw" queries in
> javascript, which seems to be a good point of injection attacks. Apart
> from this, would there be any other venues of XSS, noSQL injection
> attacks?
> I will be using mongodb with a Java middleware layer that interacts
> with the db. I wanted to enumerate the possible list of injection
> attacks (similar to SQL injection and code injection).
>
> I realize that mongodb Java driver also accepts "raw" queries in
> javascript, which seems to be a good point of injection attacks. Apart
> from this, would there be any other venues of XSS, noSQL injection
> attacks?
What do you mean by "raw" queries?
As Sam mentioned, queries are not strings -- they are bson documents.
> I am fairly new to the mongodb Java API, so I probably missed several
> weak points.
>
Amit
Mar 27, 2012, 1:52:37 PM3/27/12
to mongodb-user
This site for example explains how to use JSON strings directly in a
query (example of raw data in query).
http://www.mkyong.com/mongodb/java-mongodb-convert-json-data-to-dbobject/
Not very nice but still it is possible.
On Mar 27, 5:39 pm, Scott Hernandez <scotthernan...@gmail.com> wrote:
query (example of raw data in query).
http://www.mkyong.com/mongodb/java-mongodb-convert-json-data-to-dbobject/
Not very nice but still it is possible.
On Mar 27, 5:39 pm, Scott Hernandez <scotthernan...@gmail.com> wrote:
Sam Millman
Mar 27, 2012, 2:12:21 PM3/27/12
to mongod...@googlegroups.com
Who would in their sane mind take a unvalidated JSON string and shove it in as a new document?
The only way for this to happen is to knowing do it in which case you probably need to rethink what your trying to accomplish
The only way for this to happen is to knowing do it in which case you probably need to rethink what your trying to accomplish
Scott Hernandez
Mar 27, 2012, 9:10:12 PM3/27/12
to mongod...@googlegroups.com
As Sam suggested, why would you do that... and think it was a good thing?
Also, that is not a "raw" query but a string representation of a
json/javascript representation. A raw version would be in BSON, which
I doubt your client would provide in "raw" bits.
Don't convert string into bson and your won't have this possible problem
Amit
Mar 28, 2012, 4:34:13 AM3/28/12
to mongodb-user
Thanks for the clarification. Actually I am not planning to do any of
that!
I just want to make a list of best practices and things "to avoid"
when using MongoDB. So this seems to be one of them.
Even more problematic is direct javascript injection (which is allowed
via BasicDBObjectBuilder as discussed here:
http://grokbase.com/t/gg/mongodb-user/1226jak184/passing-js-script-in-find-in-java)
So any other things to add to the list?
Rgds
On Mar 28, 6:10 am, Scott Hernandez <scotthernan...@gmail.com> wrote:
> As Sam suggested, why would you do that... and think it was a good thing?
>
> Also, that is not a "raw" query but a string representation of a
> json/javascript representation. A raw version would be in BSON, which
> I doubt your client would provide in "raw" bits.
>
> Don't convert string into bson and your won't have this possible problem
>
>
>
>
>
>
>
> On Tue, Mar 27, 2012 at 2:12 PM, Sam Millman <sam.mill...@gmail.com> wrote:
> > Who would in their sane mind take a unvalidated JSON string and shove it in
> > as a new document?
>
> > The only way for this to happen is to knowing do it in which case you
> > probably need to rethink what your trying to accomplish
>
that!
I just want to make a list of best practices and things "to avoid"
when using MongoDB. So this seems to be one of them.
Even more problematic is direct javascript injection (which is allowed
via BasicDBObjectBuilder as discussed here:
http://grokbase.com/t/gg/mongodb-user/1226jak184/passing-js-script-in-find-in-java)
So any other things to add to the list?
Rgds
On Mar 28, 6:10 am, Scott Hernandez <scotthernan...@gmail.com> wrote:
> As Sam suggested, why would you do that... and think it was a good thing?
>
> Also, that is not a "raw" query but a string representation of a
> json/javascript representation. A raw version would be in BSON, which
> I doubt your client would provide in "raw" bits.
>
> Don't convert string into bson and your won't have this possible problem
>
>
>
>
>
>
>
> On Tue, Mar 27, 2012 at 2:12 PM, Sam Millman <sam.mill...@gmail.com> wrote:
> > Who would in their sane mind take a unvalidated JSON string and shove it in
> > as a new document?
>
> > The only way for this to happen is to knowing do it in which case you
> > probably need to rethink what your trying to accomplish
>
> > On 27 March 2012 18:52, Amit <amitabh...@gmail.com> wrote:
>
> >> This site for example explains how to use JSON strings directly in a
> >> query (example of raw data in query).
> >>http://www.mkyong.com/mongodb/java-mongodb-convert-json-data-to-dbobj...
>
> >> This site for example explains how to use JSON strings directly in a
> >> query (example of raw data in query).
Sam Millman
Mar 28, 2012, 10:45:23 AM3/28/12
to mongod...@googlegroups.com
Basically most of the time security flaws are exposed when trying to accomplish things that the driver is not designed to do.
I guess it is a matter of perspective whether you think of that as a securtiy flaw (such as where injection to get all pws in MySQL) or whether you just call it common sense (user should not be able to touch records they don't own).
Inserting JS straight into a $where is something that is allowed etc but I would not recommend it. As usual you should always use bizrules etc when deciding if the user is allowed to touch any of the returned rows (i.e. is this user allowed to touch x row).
In terms of being able to break the DB...not really, it would take some very weird queries to actually cause DB failure through it.
I guess it is a matter of perspective whether you think of that as a securtiy flaw (such as where injection to get all pws in MySQL) or whether you just call it common sense (user should not be able to touch records they don't own).
Inserting JS straight into a $where is something that is allowed etc but I would not recommend it. As usual you should always use bizrules etc when deciding if the user is allowed to touch any of the returned rows (i.e. is this user allowed to touch x row).
In terms of being able to break the DB...not really, it would take some very weird queries to actually cause DB failure through it.
Reply all
Reply to author
Forward
0 new messages