¿Cómo evita MongoDB el error de inyección de SQL?

Question

Estaba leyendo mi fiel libro de O'Reilly y encontré un pasaje sobre cómo Mongo, por naturaleza, evita el cúmulo de fallas similares a las de la inyección de SQL.

En mi instinto, creo que entiendo esto. Si VARs unsanitized se pasan a las consultas, que no pueden salir de la estructura de consulta orientada a documentos con un UNION, JOIN, consulta convertido comentario, etc.

¿Cómo evita el desorden MongoDB inyección de SQL? ¿Es solo por naturaleza de esta sintaxis de consulta?

Answer 1

MongoDB evita el potencial de problemas al no analizar.

Cualquier API, en cualquier lugar, que implique la codificación de datos de usuario en texto formateado que se analiza tiene la posibilidad de que el llamante y el destinatario no estén de acuerdo en cómo debe analizarse ese texto. Estos desacuerdos pueden ser problemas de seguridad cuando los datos se malinterpretan como metadatos. Esto es cierto ya sea que esté hablando de cadenas de formato de impresión, incluido el contenido generado por el usuario en HTML, o generando SQL.

Dado que MongoDB no analiza el texto estructurado para determinar qué hacer, no hay posibilidad de interpretar erróneamente la entrada del usuario como instrucciones, y por lo tanto, no hay un posible agujero de seguridad.

Por cierto, el consejo de evitar las API que requieren análisis es el elemento 5 en http://cr.yp.to/qmail/guarantee.html. Si está interesado en escribir un software seguro, las otras 6 sugerencias también valen la pena mirar.

Answer 2

para resumir la MongoDB documentation

BSON

Como un programa cliente monta una consulta en MongoDB, se construye un objeto BSON, no es una cadena. Por lo tanto, los ataques de inyección SQL tradicionales son sin problemas.

Sin embargo, MongoDB no es inmune a los ataques de inyección. Como se señala en la misma documentación, los ataques de inyección todavía son posibles ya que las operaciones de MongoDB permiten que se ejecuten expresiones de JavaScript arbitrarias directamente en el servidor. La documentación se dedica a esto en detalle:

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

Answer 3

Con PHP MongoDB puede llegar a ser vulnerable a la inyección n-SQL:

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

Answer 4

La base de datos podría no analiza el contenido, pero hay otras áreas del código que son vulnerables.

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

Answer 5

Para protegerse contra la inyección de SQL, los clientes pueden utilizar las API del lenguaje de MongoDB. De esta forma, toda la entrada es de valor simple: los comandos no se pueden inyectar.Un ejemplo de Java:

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

El inconveniente es que no se puede probar fácilmente el filtro. No puedes copiarlo al caparazón de Mongo y probarlo. Especialmente problemático con filtros/consultas más grandes y más complejos.

PERO !!! también hay una API para no usar la API del filtro, lo que permite analizar cualquier filtro json. ejemplo de Java a continuación:

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

Esto es bueno porque se puede copiar el filtro directamente a la consola MongoDB para probarlo.

PERO !!! (por último, lo prometo) esto es propenso a la inyección NoSql. Ejemplo de Java, donde el valor de entrada es {$gt: ""}.

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

En este último ejemplo, todo se devuelve, a pesar de que solo queremos que los registros específicos vuelvan.

Consulte here una explicación más detallada sobre la inyección SQL al usar los filtros directamente.

Una última cosa. Creo que hay una forma de usar ambos filtros sin formato y aún proteger contra la inyección de SQL. Por ejemplo, en Java, podemos usar Jongo's parameterized queries.