Inyección NoSQL: Cómo una entrada maliciosa puede comprometer tu aplicación

A diferencia de las bases de datos SQL tradicionales, que utilizan un lenguaje estructurado (SQL) para realizar consultas, las bases de datos NoSQL pueden manejar estructuras de datos no relacionales y permiten consultas más flexibles y, a menudo, menos estrictas. Por ejemplo, en las bases de datos NoSQL, las consultas pueden variar significativamente en su formato, desde documentos JSON en MongoDB, hasta consultas basadas en grafos en Neo4j. Esta flexibilidad, combinada con la falta de tipado estricto y validación en algunas implementaciones, puede llevar a fallos de seguridad significativos. 

A menudo, los desarrolladores y equipos de seguridad subestiman los riesgos de seguridad asociados con las bases de datos NoSQL debido a la falta de conocimientos especializados y a la suposición errónea de que las inyecciones relacionadas con las BBDD son un problema exclusivo de SQL. Sin embargo, en la categoría de inyecciones del OWASP, esta vulnerabilidad ocupa la tercera posición. El 94% de las aplicaciones evaluadas presentaron algún tipo de inyección, con una tasa máxima de incidencia del 19% y una tasa media de incidencia del 3%, acumulando un total de 274,000 ocurrencias.

Las inyecciones NoSQL, que afectan a las bases de datos NoSQL, como MongoDB, CouchDB, o Cassandra, ocurren cuando un atacante manipula las entradas de usuario para alterar las consultas que se realizan a una base de datos NoSQL. Los ataques de inyección NoSQL pueden ocurrir en diferentes partes de una aplicación en comparación con las inyecciones SQL tradicionales. Mientras que las inyecciones SQL se ejecutan típicamente dentro del motor de la base de datos, las variantes NoSQL pueden ejecutarse en la capa de aplicación o en la capa de base de datos, dependiendo de la API NoSQL utilizada y el modelo de datos. Por lo general, estos ataques se llevan a cabo donde la cadena maliciosa es analizada, evaluada o concatenada en una llamada de API NoSQL.

La inyección se basa en la manipulación de la estructura de la consulta para alterar la sintaxis y obtener acceso no autorizado o modificar datos. Aunque la metodología es similar a la de las inyecciones SQL, las diferencias en los lenguajes y las estructuras de consulta NoSQL requieren enfoques específicos.

Un ejemplo clásico es inyectar un operador de consulta que cambie la lógica de la consulta original. Imaginemos una aplicación web que usa MongoDB y que autentica a los usuarios verificando si el nombre de usuario y la contraseña coinciden con un registro en la base de datos:

Si userInput.username se manipula para convertirse en {"$gt": ""} y userInput.password es un valor arbitrario, la consulta podría devolver todos los registros donde el nombre de usuario sea mayor que una cadena vacía, eludiendo así la autenticación. El operador $gt en MongoDB significa “greater than” (mayor que) y, en este caso, compara el campo username con una cadena vacía (todos los documentos donde el username es mayor que una cadena vacía). Dado que la mayoría de los registros cumplen esta condición, la segunda condición (password) resulta irrelevante porque el primer filtro ya ha hecho que muchos registros pasen el primer filtro, lo que facilita eludir la autenticación. 

Veamos otro ejemplo basado en la inyección de operadores. Las bases de datos NoSQL suelen ofrecer una variedad de operadores para realizar filtrado, comparación y búsquedas avanzadas, como $or, $and, $regex y $ne en MongoDB. Un atacante puede aprovechar estos operadores para modificar la consulta y obtener acceso a datos o alterar su contenido. En MongoDB, un atacante podría usar el operador $or para modificar la consulta de autenticación y garantizar que siempre se cumpla una condición, permitiendo el acceso a la base de datos sin credenciales válidas:

En este caso, el operador $or asegura que la consulta siempre sea verdadera si se cumple cualquiera de las dos condiciones: que el password no sea igual a un valor ficticio (dummy), o que el campo password simplemente exista. De este modo, incluso si el password proporcionado es incorrecto, la consulta sigue devolviendo un resultado válido, lo que permite eludir el mecanismo de autenticación.

Factores de riesgo e impacto

Las inyecciones NoSQL representan un riesgo significativo para la seguridad de las aplicaciones web que utilizan bases de datos NoSQL. Entre estos factores de riesgo se incluyen:

• Explotación de entradas no validadas: las inyecciones NoSQL a menudo surgen cuando las aplicaciones web no validan adecuadamente las entradas del usuario. Esto permite que un atacante manipule las consultas a la base de datos mediante la inyección de datos maliciosos, lo que puede llevar a la exposición o alteración de datos sensibles. Las consultas dinámicas, que son comunes en las bases de datos NoSQL, pueden ser particularmente vulnerables si se construyen utilizando datos de entrada del usuario sin un adecuado saneamiento o parametrización. 

• Falta de controles de acceso: en algunos sistemas, la falta de controles de acceso adecuados puede permitir que los atacantes realicen consultas o modificaciones en la base de datos que normalmente estarían restringidas. Esto se agrava si las credenciales de la base de datos tienen privilegios excesivos.

• Uso inadecuado de operadores de consulta: la utilización incorrecta de operadores de consulta (como $or, $regex, etc.) en las bases de datos NoSQL puede facilitar ataques de inyección. A través de la explotación de estos operadores para manipular la lógica de las consultas y obtener acceso no autorizado a datos o alterar información.

Los impactos se refieren a las consecuencias o efectos adversos que emergen cuando se explota una vulnerabilidad. Estos impactos ilustran el daño potencial que una organización puede enfrentar si un ataque tiene éxito:

• Acceso y modificación de datos: permitiría leer, modificar o borrar datos críticos, lo que puede generar decisiones basadas en información alterada, corrupción de registros, manipulación de transacciones financieras o pérdida de datos históricos. Esto puede causar un daño irreparable a las operaciones diarias, decisiones estratégicas y reputación de la organización, y podría utilizarse para ocultar actividades fraudulentas o más ataques dañinos. La exposición de datos sensibles puede resultar en consecuencias legales y financieras, como multas por incumplimiento de normativas (por ejemplo, GDPR).

• Ejecución de código en el servidor: podría llevar a la instalación de malware, ransomware u otros programas maliciosos, comprometiendo el servidor. Esto puede interrumpir servicios, robar información, destruir datos y propagar código malicioso. También, podría permitir la escalada de privilegios o el movimiento lateral dentro de la infraestructura de TI, aumentando el riesgo de un ataque más amplio a múltiples sistemas críticos.

• Ataques de Denegación de Servicio (DoS): un atacante podría manipular consultas para sobrecargar el servidor de la base de datos, ralentizando o bloqueando aplicaciones críticas para el negocio.

Descubrimiento y evaluación de vulnerabilidades NoSQL 

A continuación, se detallan los métodos de descubrimiento de vulnerabilidades NoSQL que pueden utilizar los testers o los auditores para descubrir y corregir estas vulnerabilidades:

• Inyección de condiciones verdaderas: en esta prueba, se aprovecha el uso de una condición que siempre es verdadera, como 1 == 1, para alterar la lógica de validación y evadir las restricciones de autenticación. 

• Manipulación de condiciones de comparación: esta técnica intenta modificar las consultas utilizando operadores como $ne (not equal) para hacer que la condición siempre sea verdadera. Si el sistema no valida correctamente, se puede saltar el control de autenticación. Una manera de probar esta vulnerabilidad es usar algo como: { $ne: 1 }.

• Inyección de operadores lógicos: en este caso, se verifica si es posible manipular la consulta utilizando operadores lógicos como $or. Inyectar múltiples condiciones para asegurar que al menos una sea verdadera puede evitar los controles de validación. Un ataque podría usar: ', $or: [ {}, { 'a':'a' } ].

• Inyección con $comment: este enfoque explora si se puede inyectar un comentario en la consulta para obtener información adicional o identificar puntos débiles en la aplicación. Aunque los comentarios no cambian la lógica de la consulta, pueden ayudar a descubrir vulnerabilidades. Un ejemplo para probar esto es: $comment: 'successful MongoDB injection'.

• Inyección con bucle infinito o consumo de recursos: se trata de sobrecargar el sistema mediante la inyección de código que genere bucles infinitos o que consuma recursos. Si la aplicación no maneja correctamente estas entradas, podría ser vulnerable a un ataque de denegación de servicio. Para probar este tipo de ataque, se podría intentar con: ';sleep(5000);'.

• Inyección de expresiones regulares: esta técnica inyecta expresiones regulares en campos clave como contraseñas. Si el sistema no valida correctamente estas entradas, una expresión como /.*/ podría hacer que cualquier valor sea aceptado. Podría probarse mediante: ' && this.password.match(/.*/)//+%00.

• Inyección de comparaciones vacías: se busca eludir la autenticación mediante el uso de operadores de comparación como $gt, que seleccionan registros basados en comparaciones con valores vacíos o indefinidos. Si el sistema no valida estas comparaciones correctamente, podría devolver resultados no deseados. Esto podría probarse mediante: {"username": {"$gt": ""}}.

Medidas de protección y mejores prácticas

Para proteger las aplicaciones web contra las inyecciones NoSQL, es crucial adoptar una estrategia de seguridad que combine múltiples capas de defensa. Las bases de datos NoSQL, por su naturaleza flexible y no relacional, presentan desafíos únicos en términos de seguridad, y las técnicas que funcionan para proteger bases de datos SQL no siempre son aplicables o suficientes. A continuación, se describen las mejores prácticas y medidas de protección para mitigar las vulnerabilidades de inyección NoSQL.

• Validación estricta de entradas del usuario: la validación de entradas es la primera línea de defensa contra las inyecciones NoSQL. Es fundamental implementar controles robustos para garantizar que las entradas del usuario sean correctas y seguras:

  • Saneamiento de entradas: todas las entradas del usuario deben ser saneadas para eliminar caracteres especiales o secuencias que podrían ser utilizadas para modificar consultas. Esto incluye tanto entradas directas (formularios, parámetros de URL), como indirectas (cabeceras HTTP, cookies).

  • Validación de tipos de datos: es necesario asegurarse de que las entradas sean del tipo esperado. Por ejemplo, si se espera un número, la aplicación debe validar que la entrada es numérica y rechazar cualquier valor que no lo sea. En el caso de JSON, se deben verificar los tipos de datos esperados para evitar inyecciones de objetos JSON maliciosos.

  • Listas blancas y negras: implementar listas blancas para limitar las entradas a solo aquellos valores o caracteres que sean aceptables. Las listas negras, aunque útiles como medida secundaria, no deben ser la única defensa, ya que es difícil prever todas las posibles cargas útiles maliciosas.

• Uso de consultas parametrizadas y preparadas: el uso de consultas parametrizadas o preparadas es una de las medidas más efectivas contra las inyecciones NoSQL. Estas técnicas permiten construir consultas en las que los datos de entrada del usuario se manejan de manera segura, separándolos de la lógica de la consulta:

  • Consultas parametrizadas: estas consultas utilizan parámetros en lugar de concatenar entradas del usuario directamente en las consultas. Los parámetros permiten que la base de datos interprete los datos del usuario como simples valores de entrada, no como parte de la lógica de la consulta. En MongoDB, por ejemplo, se pueden utilizar métodos como findOne o updateOne con objetos de filtro y actualización predefinidos para evitar inyecciones.

    

  • Consultas preparadas: algunas bases de datos NoSQL, como Cassandra, admiten consultas preparadas. Estas consultas se precompilan en el servidor de la base de datos y aceptan solo valores de parámetros como entrada, minimizando el riesgo de inyección.

• Implementación de controles de acceso robustos: contar con controles de acceso bien diseñados es esencial para mitigar el riesgo de inyecciones NoSQL y otros tipos de ataques:

  • Principio de mínimos privilegios: asegurarse de que las cuentas y roles de base de datos tengan los menores privilegios posibles. Por ejemplo, una cuenta de aplicación que solo necesita leer datos no debe tener permisos de escritura o eliminación.

  • Autenticación y autorización granulares: utilizar esquemas de autenticación y autorización granulares para restringir el acceso a recursos específicos en función del rol del usuario. Además, las bases de datos permiten el uso de autenticación basada en rol (RBAC), que puede ser utilizada para definir políticas de acceso detalladas.

  • Límite de tasas y cuotas de consultas: implementar mecanismos para limitar la tasa de consultas y establecer cuotas de uso para prevenir ataques de fuerza bruta y abusos.

• Monitorización continua y detección de actividades sospechosas mediante el registro de consultas y actividades de bases de datos para detectar patrones de ataque o, implementar sistemas de detección de intrusiones (IDS) y herramientas de análisis de comportamiento que monitoricen patrones anómalos de consultas. Por ejemplo, un número inusualmente alto de consultas de lectura o modificación puede ser un indicador de un ataque en curso.

• Actualización regular y parches de seguridad, manteniendo todas las bibliotecas y bases de datos actualizadas. Las bases de datos NoSQL y sus drivers de conexión reciben actualizaciones y parches de seguridad que abordan vulnerabilidades descubiertas. Además, es necesario mantenerse al tanto de las alertas de seguridad y vulnerabilidades publicadas para la base de datos NoSQL utilizada y para todas las dependencias relacionadas, para poder aplicar las recomendaciones de seguridad lo antes posible.

Conclusión

Las inyecciones NoSQL representan una importante amenaza para la seguridad de las aplicaciones web que usan bases de datos NoSQL, principalmente debido a la flexibilidad y naturaleza dinámica de las consultas. Estas vulnerabilidades pueden poner en riesgo los pilares básicos de la seguridad de la información, por lo que, ante estos peligros, es vital adoptar un enfoque proactivo para reducir dichas amenazas.
Con el fin de proteger eficazmente las aplicaciones es necesario adoptar una estrategia de defensa ya que el panorama actual de amenazas en ciberseguridad cambia constantemente. Por ello, los desarrolladores necesitan mantenerse actualizados para responder a estas amenazas de manera efectiva. Revisar de forma continua la efectividad de estas medidas implica realizar auditorías de seguridad periódicas, test de penetración y análisis de riesgos. De esta manera, se asegura que los sistemas y aplicaciones estén mejor protegidos.