Aparte de tener una longitud de entrada excesiva, ¿hay una manera de hacer un exploit con una expresión regular (asumiendo que el lenguaje / plataforma subyacente es seguro)?
En la práctica me preguntaba si la siguiente solución en StackOverflow para usar consultas tipo LIKE en MongoDB sería seguro, a saber:
var query = { Zip: new RegExp('^' + zipCode) };
collection.find(query);
Sé que pueden poner consultas inválidas pero eso no es relevante.
Si el búfer que contiene la expresión regular tiene una longitud suficiente y el analizador de expresiones regulares se implementa utilizando un lenguaje regular y no utilizando un lenguaje completo de Turing (más precisamente, utilizando el subconjunto de instrucción de lenguaje regular de un lenguaje completo de Turing), Debería ser imposible hacer inyección de código. Una característica de los lenguajes regulares es que los casos muy simples y el flujo de control son suficientes para implementar el analizador. Si se implementa con estas herramientas de programación simples, los hacks deberían ser muy difíciles.
Tenga en cuenta que una de las mayores vulnerabilidades es el ataque de inyección de código con exceso de búfer. La forma de evitar este ataque es escribir código realmente preciso y preciso. Verifique la longitud de su búfer de manera maníaca para evitar problemas.
No creo que su pregunta tenga suficientes detalles para una respuesta definitiva. El código que publica parece estar creando un mapa con una clave de Zip y un valor que es una expresión regular. Todo lo que podemos decir es que la expresión regular comenzará con '^ ". Parece que ^ se anexa con la expresión regular" real ", llamada zipCode, pero no podemos determinar qué es eso o qué coincidirá con lo que se proporciona . Sospecho que será una clase numérica con una especificación de conteo con el número de dígitos que se permite para un código postal, pero eso es una suposición.
En general, no hay nada especial en las expresiones regulares que garanticen que una consulta sea segura o no. Puede usar una expresión regular para desinfectar o escapar de la entrada para que sea segura, pero su funcionamiento depende de qué tan bien esté escrita la expresión regular. Mi experiencia me ha enseñado que hay expresiones regulares mucho más mal escritas que bien escritas.
Sin embargo, esto podría ser un punto de silencio dependiendo de cómo se ejecuta la consulta de la base de datos real. Si la expresión regular se usa simplemente para limpiar o validar la entrada Y esa entrada solo se usa como parámetros en una declaración preparada, entonces probablemente no haya un problema. Sin embargo, si la expresión regular se usa para analizar previamente una cadena que luego se agrega a una cadena que luego se ejecuta como la consulta, entonces podría tener grandes problemas.
En general, la inyección de sql y la inyección de código en lenguajes de scripting son muy similares. En SQL, usted es vulnerable cuando crea una consulta dinámica utilizando cadenas y concatenación, y el usuario proporciona una de las cadenas. Esta es una manera muy fácil de tener sentencias SQL muy dinámicas, lo cual es tentador debido a la flexibilidad que le brinda a su usuario final. el problema es que el usuario final puede ingresar un código malicioso y causarle todo tipo de problemas. Del mismo modo, en los lenguajes con guión, el mismo problema puede ocurrir con la declaración infame 'eval', que le permite definir el código que se evaluará en el tiempo de ejecución.
La solución básica para SQL es no usar sentencias SQl generadas dinámicamente. En su lugar, utilice declaraciones preparadas que aceptan argumentos. Con las declaraciones preparadas, los argumentos proporcionados no se "ejecutan" en el mismo sentido en que se concatenan en una declaración SQl. Los motores SQl bien escritos tomarán los parámetros y realizarán varias comprobaciones para garantizar que sean válidos. esto no ocurre con una declaración de SQL dinámico construida a partir de cadenas concatenadas.
Si no tiene otra opción que usar una declaración dinámica de SQl, entonces puede usar una expresión regular para sanear los valores que el usuario proporciona, es decir, escapar o eliminar caracteres que podrían causar problemas. Si se hace correctamente, entonces debería funcionar bien. Sin embargo, es difícil hacerlo correctamente. La expresión regular puede volverse rápidamente compleja y la complejidad significa que es más fácil cometer un error sutil. El enfoque también se basa en que la persona que escribe la expresión esté al tanto de todos los trucos sutiles de inyección. He visto algunas técnicas de inyección de Oracle SQL que fueron realmente sorprendentes y no algo en lo que hubiera pensado (como usar una combinación de configuraciones de variables de entorno relacionadas con formatos de fecha y cadenas de formato de fecha SQL ingeniosamente diseñadas que a primera vista parecen ser bastante legítimo. Por esta razón, evitaría confiar en un enfoque de expresión regular para protegerme contra la inyección de código y en su lugar usaría cosas como procedimientos almacenados y declaraciones preparadas. Esto también tiene la ventaja de hacer que sea mucho más fácil probar su aplicación y verificar las cosas. Al igual que el rendimiento. Permitir consultas dinámicas, incluso si la entrada está desinfectada, puede ser una pesadilla con respecto al rendimiento. Usted puede fácilmente terminar con un problema de denegación de servicio si un usuario simplemente ingresa un recurso legal, pero extremadamente largo. Consulta intensiva. En sistemas de producción, es muy raro que desee que sus clientes puedan ejecutar cualquier tipo de consulta; Educable para un subconjunto, que puede ser grande o complejo, pero que puede asignarse a procedimientos almacenados y declaraciones preparadas.
Hay otros problemas posibles con las expresiones regulares, como las vulnerabilidades en el motor de expresiones regulares, las vulnerabilidades de desbordamiento del búfer, etc. No las estoy generando ya que creo que son mucho menos probables que la simple exposición a través de expresiones regulares mal escritas. También tenderán a ser específicos de la implementación.
Lea otras preguntas en las etiquetas exploit