¿Es seguro permitir que un usuario escriba una expresión regular como entrada de búsqueda?

Compararía aceptar expresiones regulares proporcionadas por el usuario para analizar la mayoría de las entradas de usuario estructuradas, como cadenas de fecha o markdown, en términos de riesgo de ejecución de código. Las expresiones regulares son mucho más complejas que las cadenas de fecha o la reducción (aunque la producción segura de html a partir de la reducción no confiable tiene sus propios riesgos) y, por lo tanto, representa más espacio para la explotación, pero el principio básico es el mismo: la explotación implica encontrar efectos secundarios inesperados del análisis / Proceso de compilación / emparejamiento.

La mayoría de las bibliotecas de expresiones regulares están maduras y forman parte de la biblioteca estándar en muchos idiomas, lo cual es un indicador bastante bueno (pero no cierto) de que está libre de problemas importantes que conducen a la ejecución del código.
Es decir, lo hace aumenta tu superficie de ataque, pero no es irrazonable tomar la decisión medida de aceptar ese riesgo relativamente menor.

Los ataques de denegación de servicio son un poco más complicados. Creo que la mayoría de las bibliotecas de expresiones regulares están diseñadas teniendo en cuenta el rendimiento, pero no cuentan con la mitigación de la entrada intencionalmente lenta entre sus objetivos de diseño principales. La conveniencia de aceptar expresiones regulares provistas por el usuario desde la perspectiva DoS depende más de la biblioteca.
Por ejemplo, la biblioteca de expresiones regulares .NET acepta un tiempo de espera que podría usarse para mitigar los ataques DoS.
RE2 garantiza la ejecución en tiempo lineal al tamaño de entrada que puede ser aceptable si sabe que su búsqueda se encuentra dentro de un límite de tamaño razonable.

En situaciones donde la disponibilidad es absolutamente crítica o si intentas minimizar lo más posible la superficie de ataque, tiene sentido evitar aceptar expresiones regulares de usuario, pero creo que es una práctica defendible.

La principal amenaza al aceptar expresiones regulares estará en su motor de ejecución de expresiones regulares en lugar de aceptar la expresión regular. Espero que la amenaza sea muy, muy baja en cualquier motor bien implementado. El motor no debería necesitar acceso a ningún recurso privilegiado del sistema y solo debería ejecutar la lógica en la entrada proporcionada directamente al motor. Esto significa que incluso si alguien encuentra un exploit en el intérprete, el daño que se puede hacer debe ser mínimo.

En general, todas las expresiones regulares están diseñadas para buscar patrones dentro de un valor. Siempre y cuando se respete la seguridad adecuada de los valores con los que se verifica, no hay ninguna razón para que el motor en sí tenga acceso para modificar los valores. Yo lo clasificaría como generalmente bastante seguro.

Dicho esto, también lo proporcionaría solo en situaciones en las que tenía sentido razonable hacerlo. El uso de Regex es complejo, su ejecución puede llevar mucho tiempo y su uso en los lugares equivocados podría tener algunos efectos indeseables en una aplicación fuera del contexto de seguridad, pero en el caso de uso correcto son enormemente poderosos e inmensamente valiosos. (Soy un arquitecto de software que refactoriza cientos de miles de líneas de código con regularidad).

Como han señalado las otras respuestas, el vector de ataque probablemente sería el motor de expresiones regulares.

Si bien asumirías que estos motores son bastante maduros, robustos y probados a fondo, sucedió en el pasado:

CVE-2010-1792 Ejecución de código arbitrario en Apple Safari e iOS. Cita de las Notas del parche :

  

Existe un problema de corrupción de memoria en el manejo de WebKit   de expresiones regulares. Visitar un sitio web creado con fines malintencionados puede   conducir a una terminación inesperada de la aplicación o código arbitrario   ejecución.

Pero, por supuesto, el argumento de una biblioteca posiblemente defectuosa es válida para todo, incluso archivos JPEG proporcionados por el usuario .

El otro aspecto, aunque no inherentemente técnico, sería el caso (.+) que mencionó: ¿Debería el producto permitir la recuperación de datos arbitrarios?

El problema es que los motores de expresiones regulares "retroceden". Cuando tenga una operación de reptición (por ejemplo, + o *) en su expresión regular, el motor de expresiones regulares intentará asociarla con la mayor cantidad posible de la cadena de entrada. Si la coincidencia falla más tarde, entonces retrocederá e intentará hacer coincidir su reposición con una parte más pequeña de la cadena de entrada.

Las operaciones de repetición múltiples pueden llevar a un seguimiento anidado y esto puede llevar al tiempo para evaluar la explosión de expresiones regulares masivamente, especialmente si los operadores de repetición están anidados.

enlace

No, ReDoS no requiere que el atacante cree resultados de búsqueda antinaturales.

La idea básica de ReDoS es que usted tiene una subexpresión que puede coincidir de varias maneras y en casi todas partes en la cadena buscada, excepto el final, y itera esa subexpresión para obtener un retroceso catastrófico. Por ejemplo, si la descripción de su tienda es Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. , puede usar algo como ([^q]|[^q][^q])+ (o construcciones más complejas, por ejemplo, lookaheads).

Depende de si depende el problema, como explicaron otras respuestas, puede limitar el tiempo disponible para el motor de expresiones regulares.

Respuesta corta ... No. Independientemente de si es una expresión regular o no, sigue siendo datos proporcionados por el usuario y debe NUNCA ser confiable. La práctica estándar es validar correctamente todos los datos proporcionados por el usuario ... ALWAYS!

Si desea permitir el uso de expresiones regulares por parte del usuario, entonces se debe comparar la expresión regular del usuario con una lista blanca de expresiones regulares permitidas que desea que estén disponibles para el script. De esta manera, nunca utilizará directamente la expresión regular enviada por el usuario, y si no coincide con una expresión regular en la lista blanca, puede salir del script. La única manera segura de permitir expresiones regulares como entrada del usuario que se me ocurra.