_ inyección de qstnhdr _ MongoDB Nosql en código python ____ qstntxt _

Aquí está el fragmento de código para acceder a MongoDB.
%pre%
Me dijeron que este código es vulnerable a la inyección NoSQL ya que la variable de condición no está correctamente desinfectada. Pero no pude entender cómo funciona la inyección con python. ¿Puede alguien darme un ejemplo como qué entrada puede causar los problemas o algunas referencias a un ataque de inyección relacionado? Por cierto, también hice algunas investigaciones por mi cuenta, pero solo encontré la inyección basada en Javascript y traté de no funcionar en este caso. Gracias.

____ answer83234 _

El operador %code% en MongoDB es una característica que es mejor evitar. Su rendimiento es abismal, y no solo porque no se beneficia de los índices. Casi todos los casos de uso comunes se pueden resolver de manera mucho más eficiente con una consulta o agregación de búsqueda común, especialmente una tan trivial como esta. Pero esto es un intercambio de seguridad de pila, no un flujo de pila, así que concentrémonos en las implicaciones de seguridad.
La declaración %code% pasa un fragmento de código javascript a la base de datos que la base de datos ejecutará una vez para cada documento de la colección. Afortunadamente, este script no tiene acceso al objeto %code% ni a otras funciones de shell peligrosas y funciona en copias de los documentos, por lo que el atacante al menos no puede cambiar el contenido de la base de datos como ocurre con muchas inyecciones de SQL. Pero, por ejemplo, es vulnerable a los ataques donde el atacante quiere devolver otros resultados de los previstos.

Vamos a hacer un ejemplo. Digamos que tenemos un blog. Nuestro blog tiene muchos artículos que se pueden leer en público, pero también tenemos algunos artículos privados que son para nuestro uso interno y que no deben publicarse. Así que tenemos un campo %code% en nuestros documentos que puede ser %code% o %code% dependiendo de si nuestros visitantes deben ver el artículo o no. Nuestra consulta de MongoDB para obtener una lista de todos los artículos en una categoría determinada para mostrarla al visitante del sitio web es así:
%pre%
Eso debería asegurarnos de que nadie vea nuestros artículos ocultos. O lo hace? Cuando el usuario controla la variable %code% , puede establecerla en esta cadena:
%pre%
El fragmento de código Javascript resultante que se envía a la base de datos es el siguiente:
%pre%
Cuando tiene un fragmento de código javascript con varios comandos separados por %code% , se ejecutarán como una función y se necesita una declaración %code% para determinar qué valor se devolverá al llamante. Esta función siempre devolverá verdadero. Eso significa que el usuario también verá todos los artículos de nuestra colección, incluidos aquellos que se supone que están ocultos.

____ answer83261 _


¿Puede alguien darme un ejemplo como qué entrada puede causar los problemas?

Para su pieza concreta de código, esto debería funcionar:
%pre%
%code% se usa para escapar de la cadena y la instrucción, luego sigue el ataque real %code% (ataque DOS), y luego el %code% aún en pie se transforma en una sintaxis válida a través de %code% .

Hasta la versión 2.4 de MongoDB, el objeto %code% era realmente global, por lo que podría cambiar los datos en la base de datos, e incluso recuperar datos usando inyección ciega .

Como ya no es posible, lo máximo que puede hacer un atacante es DOS y la evasión del filtro descrita por Philipp (lo que no sería un problema para su ejemplo, pero puede ser un problema en general).

Eso todavía es bastante malo, por lo que deberías defenderte escapando %code% , %code% y %code% .

___

Question

_ inyección de qstnhdr _ MongoDB Nosql en código python ____ qstntxt _

Aquí está el fragmento de código para acceder a MongoDB.
%pre%
Me dijeron que este código es vulnerable a la inyección NoSQL ya que la variable de condición no está correctamente desinfectada. Pero no pude entender cómo funciona la inyección con python. ¿Puede alguien darme un ejemplo como qué entrada puede causar los problemas o algunas referencias a un ataque de inyección relacionado? Por cierto, también hice algunas investigaciones por mi cuenta, pero solo encontré la inyección basada en Javascript y traté de no funcionar en este caso. Gracias.

____ answer83234 _

El operador %code% en MongoDB es una característica que es mejor evitar. Su rendimiento es abismal, y no solo porque no se beneficia de los índices. Casi todos los casos de uso comunes se pueden resolver de manera mucho más eficiente con una consulta o agregación de búsqueda común, especialmente una tan trivial como esta. Pero esto es un intercambio de seguridad de pila, no un flujo de pila, así que concentrémonos en las implicaciones de seguridad.
La declaración %code% pasa un fragmento de código javascript a la base de datos que la base de datos ejecutará una vez para cada documento de la colección. Afortunadamente, este script no tiene acceso al objeto %code% ni a otras funciones de shell peligrosas y funciona en copias de los documentos, por lo que el atacante al menos no puede cambiar el contenido de la base de datos como ocurre con muchas inyecciones de SQL. Pero, por ejemplo, es vulnerable a los ataques donde el atacante quiere devolver otros resultados de los previstos.

Vamos a hacer un ejemplo. Digamos que tenemos un blog. Nuestro blog tiene muchos artículos que se pueden leer en público, pero también tenemos algunos artículos privados que son para nuestro uso interno y que no deben publicarse. Así que tenemos un campo %code% en nuestros documentos que puede ser %code% o %code% dependiendo de si nuestros visitantes deben ver el artículo o no. Nuestra consulta de MongoDB para obtener una lista de todos los artículos en una categoría determinada para mostrarla al visitante del sitio web es así:
%pre%
Eso debería asegurarnos de que nadie vea nuestros artículos ocultos. O lo hace? Cuando el usuario controla la variable %code% , puede establecerla en esta cadena:
%pre%
El fragmento de código Javascript resultante que se envía a la base de datos es el siguiente:
%pre%
Cuando tiene un fragmento de código javascript con varios comandos separados por %code% , se ejecutarán como una función y se necesita una declaración %code% para determinar qué valor se devolverá al llamante. Esta función siempre devolverá verdadero. Eso significa que el usuario también verá todos los artículos de nuestra colección, incluidos aquellos que se supone que están ocultos.

____ answer83261 _


¿Puede alguien darme un ejemplo como qué entrada puede causar los problemas?

Para su pieza concreta de código, esto debería funcionar:
%pre%
%code% se usa para escapar de la cadena y la instrucción, luego sigue el ataque real %code% (ataque DOS), y luego el %code% aún en pie se transforma en una sintaxis válida a través de %code% .

Hasta la versión 2.4 de MongoDB, el objeto %code% era realmente global, por lo que podría cambiar los datos en la base de datos, e incluso recuperar datos usando inyección ciega .

Como ya no es posible, lo máximo que puede hacer un atacante es DOS y la evasión del filtro descrita por Philipp (lo que no sería un problema para su ejemplo, pero puede ser un problema en general).

Eso todavía es bastante malo, por lo que deberías defenderte escapando %code% , %code% y %code% .

___

#1 de Philipp (12 votos)
#2 de tim (7 votos)

10

Aquí está el fragmento de código para acceder a MongoDB.

client = MongoClient()
db = client.test_database
collection = db.test

# Get data from fields
condition = form.getvalue('name')
if condition:
    where = {"$where": "this.name == '"+condition+"'" }
else:
    where = ""

Me dijeron que este código es vulnerable a la inyección NoSQL ya que la variable de condición no está correctamente desinfectada. Pero no pude entender cómo funciona la inyección con python. ¿Puede alguien darme un ejemplo como qué entrada puede causar los problemas o algunas referencias a un ataque de inyección relacionado? Por cierto, también hice algunas investigaciones por mi cuenta, pero solo encontré la inyección basada en Javascript y traté de no funcionar en este caso. Gracias.

penetration-test python injection mongodb nosql

pregunta Yang Yu 07.03.2015 - 00:35

fuente

2 respuestas

7

¿Puede alguien darme un ejemplo como qué entrada puede causar los problemas?

Para su pieza concreta de código, esto debería funcionar:

'; while(1);var foo='bar

'; se usa para escapar de la cadena y la instrucción, luego sigue el ataque real while(1); (ataque DOS), y luego el ' aún en pie se transforma en una sintaxis válida a través de var foo='bar .

Hasta la versión 2.4 de MongoDB, el objeto db era realmente global, por lo que podría cambiar los datos en la base de datos, e incluso recuperar datos usando inyección ciega .

Como ya no es posible, lo máximo que puede hacer un atacante es DOS y la evasión del filtro descrita por Philipp (lo que no sería un problema para su ejemplo, pero puede ser un problema en general).

Eso todavía es bastante malo, por lo que deberías defenderte escapando ' , " y $ .

respondido por el tim 07.03.2015 - 10:54

fuente

Lea otras preguntas en las etiquetas penetration-test python injection mongodb nosql

¿Cómo se llama cuando le da una entrada a los hackers? ¿Cómo el procedimiento almacenado impide la inyección de SQL?

score 12 · Accepted Answer

El operador $where en MongoDB es una característica que es mejor evitar. Su rendimiento es abismal, y no solo porque no se beneficia de los índices. Casi todos los casos de uso comunes se pueden resolver de manera mucho más eficiente con una consulta o agregación de búsqueda común, especialmente una tan trivial como esta. Pero esto es un intercambio de seguridad de pila, no un flujo de pila, así que concentrémonos en las implicaciones de seguridad.

La declaración $where pasa un fragmento de código javascript a la base de datos que la base de datos ejecutará una vez para cada documento de la colección. Afortunadamente, este script no tiene acceso al objeto db ni a otras funciones de shell peligrosas y funciona en copias de los documentos, por lo que el atacante al menos no puede cambiar el contenido de la base de datos como ocurre con muchas inyecciones de SQL. Pero, por ejemplo, es vulnerable a los ataques donde el atacante quiere devolver otros resultados de los previstos.

Vamos a hacer un ejemplo. Digamos que tenemos un blog. Nuestro blog tiene muchos artículos que se pueden leer en público, pero también tenemos algunos artículos privados que son para nuestro uso interno y que no deben publicarse. Así que tenemos un campo hidden en nuestros documentos que puede ser true o false dependiendo de si nuestros visitantes deben ver el artículo o no. Nuestra consulta de MongoDB para obtener una lista de todos los artículos en una categoría determinada para mostrarla al visitante del sitio web es así:

db.articles.find({"$where": "this.hidden == false && this.category == '"+category+"'" });

Eso debería asegurarnos de que nadie vea nuestros artículos ocultos. O lo hace? Cuando el usuario controla la variable category , puede establecerla en esta cadena:

'; return '' == '

El fragmento de código Javascript resultante que se envía a la base de datos es el siguiente:

this.hidden == false && this.category == ''; return '' == ''

Cuando tiene un fragmento de código javascript con varios comandos separados por ; , se ejecutarán como una función y se necesita una declaración return para determinar qué valor se devolverá al llamante. Esta función siempre devolverá verdadero. Eso significa que el usuario también verá todos los artículos de nuestra colección, incluidos aquellos que se supone que están ocultos.