Coders Conquer Security: Share & Learn Series - Inyección NoSQL
Las bases de datos NoSQL son cada vez más populares. Es difícil negar su velocidad y facilidad para tratar datos no estructurados, especialmente con equipos de desarrollo que trabajan con metodologías cada vez más ágiles.
Los desarrolladores tardan en eliminar las vulnerabilidades y otros problemas de la tecnología emergente. Sólo cuando se ha utilizado durante algún tiempo en aplicaciones de producción, los problemas empiezan a salir a la superficie.
Las bases de datos NoSQL son similares. Hay riesgos clave que los desarrolladores deben conocer para poder mantener sus aplicaciones seguras. Uno de estos riesgos es la inyección NoSQL.
Veamos qué es la inyección NoSQL, qué daños puede causar y cómo solucionarla:
Entender la inyección NoSQL
La inyección NoSQL es causada por muchas de las mismas vulnerabilidades de inyección como la inyección XML o SQL.
La inyección NoSQL permite a los atacantes colocar comandos arbitrarios en una consulta NoSQL. Esto les permite robar datos e incluso realizar cambios en la base de datos si sus privilegios son lo suficientemente altos.
Cuando una aplicación coloca datos controlados por el usuario directamente en una expresión de consulta NoSQL, estas expresiones a menudo toman funciones o tienen operadores incorporados que pueden ser manipulados para robar o cambiar datos. Y cuando algo así se ejecuta con intención maliciosa, las consecuencias pueden ser nefastas.
Las bases de datos MongoDB son uno de los terrenos de juego más populares para explotar esta vulnerabilidad. "$ne: ""'es el operador equivalente a 1=1 en el mundo SQL, por lo que, a modo de ejemplo, un atacante podría colocar los caracteres "$ne: ""' en los campos de nombre de usuario y contraseña de una interfaz de usuario. Si el código es vulnerable a la inyección NoSQL, la base de datos buscará todos los registros en los que el nombre de usuario y la contraseña no sean iguales a una cadena vacía. En otras palabras: todos. Vaya.
Si esta base de datos no está cifrada, el atacante podría robar los nombres de usuario y las contraseñas de cada uno de los usuarios que la componen. Esto incluye los nombres de usuario y las contraseñas de los administradores, dándoles un pase de acceso a toda la base de datos.
Los atacantes a menudo tratan de pasar valores que siempre son verdaderos. Otro ataque común es inyectar código malicioso en las propiedades que se establecen en las funciones.
Por ejemplo, MongoDB utiliza una función find que toma un objeto con una propiedad llamada $where. La propiedad $where se establece en una función que debe evaluarse como verdadera o falsa. Si esta función se modifica de alguna manera por la entrada del usuario, es probable que una inyección NoSQL esté al acecho.
Para conocer con detalle los entresijos de la inyección NoSQL, consulte este artículo de InfoQ.
Sepa por qué la inyección NoSQL es peligrosa
La inyección NoSQL es peligrosa sobre todo porque todavía no ha recibido el escrutinio de la comunidad de seguridad que merece.
Los impactos de la inyección NoSQL son muy parecidos a los de la inyección SQL tradicional. Los datos pueden ser robados o modificados, las cuentas pueden verse comprometidas por el robo de datos y, tal vez lo más cruel, los datos podrían ser completamente borrados si se emite con éxito un comando de borrado.
La conclusión es que MongoDB y otros motores de bases de datos NoSQL son vulnerables a los ataques. "No SQL" no significa que no haya inyecciones.
Afortunadamente, algunos miembros de la comunidad están tomando nota y corriendo la voz. Es necesario que más desarrolladores se eduquen para poder proteger sus aplicaciones de peligros poco conocidos que pueden convertirse en un gran dolor de cabeza si son explotados.
Derrotar la inyección NoSQL
La inyección NoSQL puede ser difícil de vencer. Por desgracia, no existe la opción de realizar consultas parametrizadas como ocurre con la inyección SQL. Sin embargo, no es imposible. Hay algunas opciones para ayudarte:
- Los fuzzers pueden utilizarse como un método para detectar vulnerabilidades. Aunque, como ocurre con muchas cosas en la vida, el enfoque más sencillo puede ser el más eficaz. En este caso, la vieja revisión de código es tu mejor aliado.
- Cuando revise el código, busque posibles lugares donde la entrada del usuario pueda establecer el valor de una expresión o cambiar una función. No permitas que la entrada del usuario cambie tus consultas.
- Asegúrese de convertir la entrada del usuario a su clase correcta. Si es un número, cámbialo a un número, si es una cadena, cámbialo a una cadena y así sucesivamente.
- Nunca utilice $where o funciones eval similares junto con la entrada del usuario. En la mayoría de los casos, se puede evitar cambiando el modelo de datos o el esquema.
- Prueba a utilizar Mongoose como tu controlador de MongoDB. Mongoose le permite definir un esquema para su base de datos NoSQL. Si le dices a Mongoose que tus entradas son cadenas, se convertirán en cadenas. Así, cualquier objeto pasado por un atacante no será tratado como objeto, sino como cadena.
- Endurezca su base de datos. Cree cuentas de usuario con pocos privilegios, maximice el tiempo de ejecución de las consultas y siga siempre las mejores prácticas de seguridad aplicables a su organización.
Una desventaja de la facilidad de uso de las bases de datos NoSQL es la tendencia de los desarrolladores a montarlas y empezar a utilizarlas sin pensar en la seguridad.
Es esencial que te tomes el tiempo necesario para aprender a levantar de forma segura una base de datos NoSQL y protegerte de las inyecciones NoSQL.
Por ejemplo, MongoDB Enterprise Edition tiene capacidades avanzadas de control de acceso para sus documentos. Aplicar el "mínimo privilegio" puede ser una buena estrategia de Defensa en Profundidad (DiD) en caso de que alguien encuentre una vulnerabilidad en tu aplicación.
En resumen, esto es lo que tenemos:
- Sanear la entrada antes de utilizarla en una expresión de consulta NoSQL
- Utiliza controladores que te ayuden, como Mongoose
- Realización de revisiones de código que examinen específicamente cómo se utilizan los datos de entrada en las consultas
- Utilice fuzzers y escáneres para tratar de ayudar a encontrar vulnerabilidades en su código.
NoSQL no es sin inyecciones
Las bases de datos NoSQL están ganando rápidamente popularidad debido a sus características de escalabilidad y a la velocidad de configuración. La novedad de la tecnología puede llevar a los desarrolladores a utilizar las bases de datos NoSQL sin pensar en cómo asegurarlas.
Las bases de datos NoSQL pueden ser tan vulnerables como las bases de datos SQL a los ataques de inyección, así que actúa con precaución y presta atención a tus consultas. Si quieres saber más, echa un vistazo a nuestros recursos de aprendizaje o pon a prueba tus habilidades con nuestra demo gratuita.
Prepárese con antelación y no tendrá que preocuparse por las inyecciones NoSQL en sus aplicaciones. Demasiado fácil!
¿Crees que estás preparado para localizar, identificar y arreglar la inyección NoSQL ahora mismo? Entra en el terreno del código seguro, guerrero:
Y con esto terminamos el 2018! Este será nuestro último post del año, pero volveremos con la próxima guía de Coders Conquer Security el 10 de enero de 2019. Nos vemos pronto!
Las bases de datos NoSQL son cada vez más populares. Es difícil negar su rapidez y facilidad para tratar datos no estructurados, pero a medida que su uso se generaliza, inevitablemente afloran más vulnerabilidades.
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
Las bases de datos NoSQL son cada vez más populares. Es difícil negar su velocidad y facilidad para tratar datos no estructurados, especialmente con equipos de desarrollo que trabajan con metodologías cada vez más ágiles.
Los desarrolladores tardan en eliminar las vulnerabilidades y otros problemas de la tecnología emergente. Sólo cuando se ha utilizado durante algún tiempo en aplicaciones de producción, los problemas empiezan a salir a la superficie.
Las bases de datos NoSQL son similares. Hay riesgos clave que los desarrolladores deben conocer para poder mantener sus aplicaciones seguras. Uno de estos riesgos es la inyección NoSQL.
Veamos qué es la inyección NoSQL, qué daños puede causar y cómo solucionarla:
Entender la inyección NoSQL
La inyección NoSQL es causada por muchas de las mismas vulnerabilidades de inyección como la inyección XML o SQL.
La inyección NoSQL permite a los atacantes colocar comandos arbitrarios en una consulta NoSQL. Esto les permite robar datos e incluso realizar cambios en la base de datos si sus privilegios son lo suficientemente altos.
Cuando una aplicación coloca datos controlados por el usuario directamente en una expresión de consulta NoSQL, estas expresiones a menudo toman funciones o tienen operadores incorporados que pueden ser manipulados para robar o cambiar datos. Y cuando algo así se ejecuta con intención maliciosa, las consecuencias pueden ser nefastas.
Las bases de datos MongoDB son uno de los terrenos de juego más populares para explotar esta vulnerabilidad. "$ne: ""'es el operador equivalente a 1=1 en el mundo SQL, por lo que, a modo de ejemplo, un atacante podría colocar los caracteres "$ne: ""' en los campos de nombre de usuario y contraseña de una interfaz de usuario. Si el código es vulnerable a la inyección NoSQL, la base de datos buscará todos los registros en los que el nombre de usuario y la contraseña no sean iguales a una cadena vacía. En otras palabras: todos. Vaya.
Si esta base de datos no está cifrada, el atacante podría robar los nombres de usuario y las contraseñas de cada uno de los usuarios que la componen. Esto incluye los nombres de usuario y las contraseñas de los administradores, dándoles un pase de acceso a toda la base de datos.
Los atacantes a menudo tratan de pasar valores que siempre son verdaderos. Otro ataque común es inyectar código malicioso en las propiedades que se establecen en las funciones.
Por ejemplo, MongoDB utiliza una función find que toma un objeto con una propiedad llamada $where. La propiedad $where se establece en una función que debe evaluarse como verdadera o falsa. Si esta función se modifica de alguna manera por la entrada del usuario, es probable que una inyección NoSQL esté al acecho.
Para conocer con detalle los entresijos de la inyección NoSQL, consulte este artículo de InfoQ.
Sepa por qué la inyección NoSQL es peligrosa
La inyección NoSQL es peligrosa sobre todo porque todavía no ha recibido el escrutinio de la comunidad de seguridad que merece.
Los impactos de la inyección NoSQL son muy parecidos a los de la inyección SQL tradicional. Los datos pueden ser robados o modificados, las cuentas pueden verse comprometidas por el robo de datos y, tal vez lo más cruel, los datos podrían ser completamente borrados si se emite con éxito un comando de borrado.
La conclusión es que MongoDB y otros motores de bases de datos NoSQL son vulnerables a los ataques. "No SQL" no significa que no haya inyecciones.
Afortunadamente, algunos miembros de la comunidad están tomando nota y corriendo la voz. Es necesario que más desarrolladores se eduquen para poder proteger sus aplicaciones de peligros poco conocidos que pueden convertirse en un gran dolor de cabeza si son explotados.
Derrotar la inyección NoSQL
La inyección NoSQL puede ser difícil de vencer. Por desgracia, no existe la opción de realizar consultas parametrizadas como ocurre con la inyección SQL. Sin embargo, no es imposible. Hay algunas opciones para ayudarte:
- Los fuzzers pueden utilizarse como un método para detectar vulnerabilidades. Aunque, como ocurre con muchas cosas en la vida, el enfoque más sencillo puede ser el más eficaz. En este caso, la vieja revisión de código es tu mejor aliado.
- Cuando revise el código, busque posibles lugares donde la entrada del usuario pueda establecer el valor de una expresión o cambiar una función. No permitas que la entrada del usuario cambie tus consultas.
- Asegúrese de convertir la entrada del usuario a su clase correcta. Si es un número, cámbialo a un número, si es una cadena, cámbialo a una cadena y así sucesivamente.
- Nunca utilice $where o funciones eval similares junto con la entrada del usuario. En la mayoría de los casos, se puede evitar cambiando el modelo de datos o el esquema.
- Prueba a utilizar Mongoose como tu controlador de MongoDB. Mongoose le permite definir un esquema para su base de datos NoSQL. Si le dices a Mongoose que tus entradas son cadenas, se convertirán en cadenas. Así, cualquier objeto pasado por un atacante no será tratado como objeto, sino como cadena.
- Endurezca su base de datos. Cree cuentas de usuario con pocos privilegios, maximice el tiempo de ejecución de las consultas y siga siempre las mejores prácticas de seguridad aplicables a su organización.
Una desventaja de la facilidad de uso de las bases de datos NoSQL es la tendencia de los desarrolladores a montarlas y empezar a utilizarlas sin pensar en la seguridad.
Es esencial que te tomes el tiempo necesario para aprender a levantar de forma segura una base de datos NoSQL y protegerte de las inyecciones NoSQL.
Por ejemplo, MongoDB Enterprise Edition tiene capacidades avanzadas de control de acceso para sus documentos. Aplicar el "mínimo privilegio" puede ser una buena estrategia de Defensa en Profundidad (DiD) en caso de que alguien encuentre una vulnerabilidad en tu aplicación.
En resumen, esto es lo que tenemos:
- Sanear la entrada antes de utilizarla en una expresión de consulta NoSQL
- Utiliza controladores que te ayuden, como Mongoose
- Realización de revisiones de código que examinen específicamente cómo se utilizan los datos de entrada en las consultas
- Utilice fuzzers y escáneres para tratar de ayudar a encontrar vulnerabilidades en su código.
NoSQL no es sin inyecciones
Las bases de datos NoSQL están ganando rápidamente popularidad debido a sus características de escalabilidad y a la velocidad de configuración. La novedad de la tecnología puede llevar a los desarrolladores a utilizar las bases de datos NoSQL sin pensar en cómo asegurarlas.
Las bases de datos NoSQL pueden ser tan vulnerables como las bases de datos SQL a los ataques de inyección, así que actúa con precaución y presta atención a tus consultas. Si quieres saber más, echa un vistazo a nuestros recursos de aprendizaje o pon a prueba tus habilidades con nuestra demo gratuita.
Prepárese con antelación y no tendrá que preocuparse por las inyecciones NoSQL en sus aplicaciones. Demasiado fácil!
¿Crees que estás preparado para localizar, identificar y arreglar la inyección NoSQL ahora mismo? Entra en el terreno del código seguro, guerrero:
Y con esto terminamos el 2018! Este será nuestro último post del año, pero volveremos con la próxima guía de Coders Conquer Security el 10 de enero de 2019. Nos vemos pronto!
Las bases de datos NoSQL son cada vez más populares. Es difícil negar su velocidad y facilidad para tratar datos no estructurados, especialmente con equipos de desarrollo que trabajan con metodologías cada vez más ágiles.
Los desarrolladores tardan en eliminar las vulnerabilidades y otros problemas de la tecnología emergente. Sólo cuando se ha utilizado durante algún tiempo en aplicaciones de producción, los problemas empiezan a salir a la superficie.
Las bases de datos NoSQL son similares. Hay riesgos clave que los desarrolladores deben conocer para poder mantener sus aplicaciones seguras. Uno de estos riesgos es la inyección NoSQL.
Veamos qué es la inyección NoSQL, qué daños puede causar y cómo solucionarla:
Entender la inyección NoSQL
La inyección NoSQL es causada por muchas de las mismas vulnerabilidades de inyección como la inyección XML o SQL.
La inyección NoSQL permite a los atacantes colocar comandos arbitrarios en una consulta NoSQL. Esto les permite robar datos e incluso realizar cambios en la base de datos si sus privilegios son lo suficientemente altos.
Cuando una aplicación coloca datos controlados por el usuario directamente en una expresión de consulta NoSQL, estas expresiones a menudo toman funciones o tienen operadores incorporados que pueden ser manipulados para robar o cambiar datos. Y cuando algo así se ejecuta con intención maliciosa, las consecuencias pueden ser nefastas.
Las bases de datos MongoDB son uno de los terrenos de juego más populares para explotar esta vulnerabilidad. "$ne: ""'es el operador equivalente a 1=1 en el mundo SQL, por lo que, a modo de ejemplo, un atacante podría colocar los caracteres "$ne: ""' en los campos de nombre de usuario y contraseña de una interfaz de usuario. Si el código es vulnerable a la inyección NoSQL, la base de datos buscará todos los registros en los que el nombre de usuario y la contraseña no sean iguales a una cadena vacía. En otras palabras: todos. Vaya.
Si esta base de datos no está cifrada, el atacante podría robar los nombres de usuario y las contraseñas de cada uno de los usuarios que la componen. Esto incluye los nombres de usuario y las contraseñas de los administradores, dándoles un pase de acceso a toda la base de datos.
Los atacantes a menudo tratan de pasar valores que siempre son verdaderos. Otro ataque común es inyectar código malicioso en las propiedades que se establecen en las funciones.
Por ejemplo, MongoDB utiliza una función find que toma un objeto con una propiedad llamada $where. La propiedad $where se establece en una función que debe evaluarse como verdadera o falsa. Si esta función se modifica de alguna manera por la entrada del usuario, es probable que una inyección NoSQL esté al acecho.
Para conocer con detalle los entresijos de la inyección NoSQL, consulte este artículo de InfoQ.
Sepa por qué la inyección NoSQL es peligrosa
La inyección NoSQL es peligrosa sobre todo porque todavía no ha recibido el escrutinio de la comunidad de seguridad que merece.
Los impactos de la inyección NoSQL son muy parecidos a los de la inyección SQL tradicional. Los datos pueden ser robados o modificados, las cuentas pueden verse comprometidas por el robo de datos y, tal vez lo más cruel, los datos podrían ser completamente borrados si se emite con éxito un comando de borrado.
La conclusión es que MongoDB y otros motores de bases de datos NoSQL son vulnerables a los ataques. "No SQL" no significa que no haya inyecciones.
Afortunadamente, algunos miembros de la comunidad están tomando nota y corriendo la voz. Es necesario que más desarrolladores se eduquen para poder proteger sus aplicaciones de peligros poco conocidos que pueden convertirse en un gran dolor de cabeza si son explotados.
Derrotar la inyección NoSQL
La inyección NoSQL puede ser difícil de vencer. Por desgracia, no existe la opción de realizar consultas parametrizadas como ocurre con la inyección SQL. Sin embargo, no es imposible. Hay algunas opciones para ayudarte:
- Los fuzzers pueden utilizarse como un método para detectar vulnerabilidades. Aunque, como ocurre con muchas cosas en la vida, el enfoque más sencillo puede ser el más eficaz. En este caso, la vieja revisión de código es tu mejor aliado.
- Cuando revise el código, busque posibles lugares donde la entrada del usuario pueda establecer el valor de una expresión o cambiar una función. No permitas que la entrada del usuario cambie tus consultas.
- Asegúrese de convertir la entrada del usuario a su clase correcta. Si es un número, cámbialo a un número, si es una cadena, cámbialo a una cadena y así sucesivamente.
- Nunca utilice $where o funciones eval similares junto con la entrada del usuario. En la mayoría de los casos, se puede evitar cambiando el modelo de datos o el esquema.
- Prueba a utilizar Mongoose como tu controlador de MongoDB. Mongoose le permite definir un esquema para su base de datos NoSQL. Si le dices a Mongoose que tus entradas son cadenas, se convertirán en cadenas. Así, cualquier objeto pasado por un atacante no será tratado como objeto, sino como cadena.
- Endurezca su base de datos. Cree cuentas de usuario con pocos privilegios, maximice el tiempo de ejecución de las consultas y siga siempre las mejores prácticas de seguridad aplicables a su organización.
Una desventaja de la facilidad de uso de las bases de datos NoSQL es la tendencia de los desarrolladores a montarlas y empezar a utilizarlas sin pensar en la seguridad.
Es esencial que te tomes el tiempo necesario para aprender a levantar de forma segura una base de datos NoSQL y protegerte de las inyecciones NoSQL.
Por ejemplo, MongoDB Enterprise Edition tiene capacidades avanzadas de control de acceso para sus documentos. Aplicar el "mínimo privilegio" puede ser una buena estrategia de Defensa en Profundidad (DiD) en caso de que alguien encuentre una vulnerabilidad en tu aplicación.
En resumen, esto es lo que tenemos:
- Sanear la entrada antes de utilizarla en una expresión de consulta NoSQL
- Utiliza controladores que te ayuden, como Mongoose
- Realización de revisiones de código que examinen específicamente cómo se utilizan los datos de entrada en las consultas
- Utilice fuzzers y escáneres para tratar de ayudar a encontrar vulnerabilidades en su código.
NoSQL no es sin inyecciones
Las bases de datos NoSQL están ganando rápidamente popularidad debido a sus características de escalabilidad y a la velocidad de configuración. La novedad de la tecnología puede llevar a los desarrolladores a utilizar las bases de datos NoSQL sin pensar en cómo asegurarlas.
Las bases de datos NoSQL pueden ser tan vulnerables como las bases de datos SQL a los ataques de inyección, así que actúa con precaución y presta atención a tus consultas. Si quieres saber más, echa un vistazo a nuestros recursos de aprendizaje o pon a prueba tus habilidades con nuestra demo gratuita.
Prepárese con antelación y no tendrá que preocuparse por las inyecciones NoSQL en sus aplicaciones. Demasiado fácil!
¿Crees que estás preparado para localizar, identificar y arreglar la inyección NoSQL ahora mismo? Entra en el terreno del código seguro, guerrero:
Y con esto terminamos el 2018! Este será nuestro último post del año, pero volveremos con la próxima guía de Coders Conquer Security el 10 de enero de 2019. Nos vemos pronto!
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
Las bases de datos NoSQL son cada vez más populares. Es difícil negar su velocidad y facilidad para tratar datos no estructurados, especialmente con equipos de desarrollo que trabajan con metodologías cada vez más ágiles.
Los desarrolladores tardan en eliminar las vulnerabilidades y otros problemas de la tecnología emergente. Sólo cuando se ha utilizado durante algún tiempo en aplicaciones de producción, los problemas empiezan a salir a la superficie.
Las bases de datos NoSQL son similares. Hay riesgos clave que los desarrolladores deben conocer para poder mantener sus aplicaciones seguras. Uno de estos riesgos es la inyección NoSQL.
Veamos qué es la inyección NoSQL, qué daños puede causar y cómo solucionarla:
Entender la inyección NoSQL
La inyección NoSQL es causada por muchas de las mismas vulnerabilidades de inyección como la inyección XML o SQL.
La inyección NoSQL permite a los atacantes colocar comandos arbitrarios en una consulta NoSQL. Esto les permite robar datos e incluso realizar cambios en la base de datos si sus privilegios son lo suficientemente altos.
Cuando una aplicación coloca datos controlados por el usuario directamente en una expresión de consulta NoSQL, estas expresiones a menudo toman funciones o tienen operadores incorporados que pueden ser manipulados para robar o cambiar datos. Y cuando algo así se ejecuta con intención maliciosa, las consecuencias pueden ser nefastas.
Las bases de datos MongoDB son uno de los terrenos de juego más populares para explotar esta vulnerabilidad. "$ne: ""'es el operador equivalente a 1=1 en el mundo SQL, por lo que, a modo de ejemplo, un atacante podría colocar los caracteres "$ne: ""' en los campos de nombre de usuario y contraseña de una interfaz de usuario. Si el código es vulnerable a la inyección NoSQL, la base de datos buscará todos los registros en los que el nombre de usuario y la contraseña no sean iguales a una cadena vacía. En otras palabras: todos. Vaya.
Si esta base de datos no está cifrada, el atacante podría robar los nombres de usuario y las contraseñas de cada uno de los usuarios que la componen. Esto incluye los nombres de usuario y las contraseñas de los administradores, dándoles un pase de acceso a toda la base de datos.
Los atacantes a menudo tratan de pasar valores que siempre son verdaderos. Otro ataque común es inyectar código malicioso en las propiedades que se establecen en las funciones.
Por ejemplo, MongoDB utiliza una función find que toma un objeto con una propiedad llamada $where. La propiedad $where se establece en una función que debe evaluarse como verdadera o falsa. Si esta función se modifica de alguna manera por la entrada del usuario, es probable que una inyección NoSQL esté al acecho.
Para conocer con detalle los entresijos de la inyección NoSQL, consulte este artículo de InfoQ.
Sepa por qué la inyección NoSQL es peligrosa
La inyección NoSQL es peligrosa sobre todo porque todavía no ha recibido el escrutinio de la comunidad de seguridad que merece.
Los impactos de la inyección NoSQL son muy parecidos a los de la inyección SQL tradicional. Los datos pueden ser robados o modificados, las cuentas pueden verse comprometidas por el robo de datos y, tal vez lo más cruel, los datos podrían ser completamente borrados si se emite con éxito un comando de borrado.
La conclusión es que MongoDB y otros motores de bases de datos NoSQL son vulnerables a los ataques. "No SQL" no significa que no haya inyecciones.
Afortunadamente, algunos miembros de la comunidad están tomando nota y corriendo la voz. Es necesario que más desarrolladores se eduquen para poder proteger sus aplicaciones de peligros poco conocidos que pueden convertirse en un gran dolor de cabeza si son explotados.
Derrotar la inyección NoSQL
La inyección NoSQL puede ser difícil de vencer. Por desgracia, no existe la opción de realizar consultas parametrizadas como ocurre con la inyección SQL. Sin embargo, no es imposible. Hay algunas opciones para ayudarte:
- Los fuzzers pueden utilizarse como un método para detectar vulnerabilidades. Aunque, como ocurre con muchas cosas en la vida, el enfoque más sencillo puede ser el más eficaz. En este caso, la vieja revisión de código es tu mejor aliado.
- Cuando revise el código, busque posibles lugares donde la entrada del usuario pueda establecer el valor de una expresión o cambiar una función. No permitas que la entrada del usuario cambie tus consultas.
- Asegúrese de convertir la entrada del usuario a su clase correcta. Si es un número, cámbialo a un número, si es una cadena, cámbialo a una cadena y así sucesivamente.
- Nunca utilice $where o funciones eval similares junto con la entrada del usuario. En la mayoría de los casos, se puede evitar cambiando el modelo de datos o el esquema.
- Prueba a utilizar Mongoose como tu controlador de MongoDB. Mongoose le permite definir un esquema para su base de datos NoSQL. Si le dices a Mongoose que tus entradas son cadenas, se convertirán en cadenas. Así, cualquier objeto pasado por un atacante no será tratado como objeto, sino como cadena.
- Endurezca su base de datos. Cree cuentas de usuario con pocos privilegios, maximice el tiempo de ejecución de las consultas y siga siempre las mejores prácticas de seguridad aplicables a su organización.
Una desventaja de la facilidad de uso de las bases de datos NoSQL es la tendencia de los desarrolladores a montarlas y empezar a utilizarlas sin pensar en la seguridad.
Es esencial que te tomes el tiempo necesario para aprender a levantar de forma segura una base de datos NoSQL y protegerte de las inyecciones NoSQL.
Por ejemplo, MongoDB Enterprise Edition tiene capacidades avanzadas de control de acceso para sus documentos. Aplicar el "mínimo privilegio" puede ser una buena estrategia de Defensa en Profundidad (DiD) en caso de que alguien encuentre una vulnerabilidad en tu aplicación.
En resumen, esto es lo que tenemos:
- Sanear la entrada antes de utilizarla en una expresión de consulta NoSQL
- Utiliza controladores que te ayuden, como Mongoose
- Realización de revisiones de código que examinen específicamente cómo se utilizan los datos de entrada en las consultas
- Utilice fuzzers y escáneres para tratar de ayudar a encontrar vulnerabilidades en su código.
NoSQL no es sin inyecciones
Las bases de datos NoSQL están ganando rápidamente popularidad debido a sus características de escalabilidad y a la velocidad de configuración. La novedad de la tecnología puede llevar a los desarrolladores a utilizar las bases de datos NoSQL sin pensar en cómo asegurarlas.
Las bases de datos NoSQL pueden ser tan vulnerables como las bases de datos SQL a los ataques de inyección, así que actúa con precaución y presta atención a tus consultas. Si quieres saber más, echa un vistazo a nuestros recursos de aprendizaje o pon a prueba tus habilidades con nuestra demo gratuita.
Prepárese con antelación y no tendrá que preocuparse por las inyecciones NoSQL en sus aplicaciones. Demasiado fácil!
¿Crees que estás preparado para localizar, identificar y arreglar la inyección NoSQL ahora mismo? Entra en el terreno del código seguro, guerrero:
Y con esto terminamos el 2018! Este será nuestro último post del año, pero volveremos con la próxima guía de Coders Conquer Security el 10 de enero de 2019. Nos vemos pronto!
Índice
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Panorama de la gestión de riesgos de los promotores
La gestión de riesgos del desarrollador es un enfoque holístico y proactivo de la seguridad de las aplicaciones, centrado en quienes contribuyen al código y no en los bits y bytes de la propia capa de la aplicación.
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Servicios profesionales - Acelerar con experiencia
El equipo de servicios de estrategia de programas (PSS) de Secure Code Warriorle ayuda a crear, mejorar y optimizar su programa de codificación segura. Tanto si empieza de cero como si está perfeccionando su enfoque, nuestros expertos le proporcionarán orientación personalizada.
Recursos para empezar
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
