6 ms·

Thanks to $elemMatch and automatic parameter parsing, this vulnerability is easier to exploit than it would seem. In rails, both of these are usually considere

Thanks to $elemMatch and automatic parameter parsing, this vulnerability is easier to exploit than it would seem. In rails, both of these are usually considered safe: MysqlCollection.create(:name => params[:name]) MysqlCollection.where(:name => params[:name]).all MongoCollection.create(:name => params[:name]) MongoCollection.where(:name => params[:name]).all However, the mongo version is vulnerable to this exploit. /create?name[0][whatever]=anything /get?name[$elemMatch][$where]=exploitcode

cheald 13y ago
Per usual, even if you're using something that isn't Mongo, it's good practice to explicitly cast your untrusted params before passing them to a query. MongoCollection.where(:name => params[:name].to_s) That'll result in the literal: db.collection.where({name: "{\"$elemMatch\"=>{\"$where\"=>\"exploit\"}}"}) rather than the more exploity: db.collection.where({name: {$elemMatch:{$where: "exploit"}}}) Failing to cast params to strings can result in "injection" attacks in Mongo, even outside of the context of this bug. For example: User.where(:id => params[:id]) You could pass id[$gt]=0, resulting in: User.where(:id => {:$gt => 0}) which would match all records in the database. For completeness' sake, here's a similar exploit vector in ActiveRecord: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/t1WFuuQyavI https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...