Regla
Proteger contra lento regulares lentas.
Expresiones regulares regulares con anidadas anidados o 
ambiguos ambiguos pueden causar catastróficas 
retroceso y rendimiento rendimiento.
Idiomas compatibles: 45+

Introducción

Las expresiones regulares pueden congelar su aplicación durante segundos o minutos con la entrada adecuada. El backtracking catastrófico ocurre cuando los motores de regex exploran rutas que aumentan exponencialmente al intentar hacer coincidir un patrón. Una regex como (a+)+b tarda microsegundos en coincidir con una entrada válida, pero puede tardar horas en rechazar una cadena de 'a' sin una 'b' final. Los atacantes explotan esto mediante ataques de Denegación de Servicio por Expresiones Regulares (ReDoS), enviando entradas maliciosas que hacen que su motor de expresiones regulares consuma el 100% de la CPU hasta que se agoten los tiempos de espera de la solicitud o el proceso falle.

Por qué es importante

Implicaciones de seguridad (ataques ReDoS): Un atacante puede paralizar su aplicación con una única solicitud que contenga una entrada maliciosa. La validación de correos electrónicos y los patrones de análisis de URL son objetivos comunes. A diferencia de los ataques DoS tradicionales que requieren ancho de banda, ReDoS solo necesita cargas útiles muy pequeñas.

Degradación del rendimiento: La entrada normal del usuario puede desencadenar un retroceso catastrófico, haciendo que los tiempos de respuesta se disparen de milisegundos a segundos. Esto crea una latencia impredecible que es difícil de depurar porque solo se manifiesta con patrones de entrada específicos.

Incidentes en producción: Una expresión regular (regex) vulnerable bloquea el bucle de eventos en Node.js o consume recursos del pool de hilos. A medida que las solicitudes se acumulan, la memoria aumenta y el sistema deja de responder. En microservicios, una regex vulnerable propaga fallos a los servicios dependientes.

Dificultad en la detección: Los patrones que funcionan bien en pruebas con entradas cortas se vuelven exponencialmente lentos con entradas más largas. La vulnerabilidad a menudo pasa desapercibida hasta la producción, requiriendo un despliegue de emergencia durante un incidente activo.

Ejemplos de código

❌ No conforme:

function validateEmail(email) {
    const regex = /^([a-zA-Z0-9_\-\.]+)+@([a-zA-Z0-9_\-\.]+)+\.([a-zA-Z]{2,5})$/;
    return regex.test(email);
}

function extractURLs(text) {
    const regex = /(https?:\/\/)?([\w\-])+\.(\w+)+([\w\-\.,@?^=%&:/~\+#]*)+/g;
    return text.match(regex);
}

Por qué es inseguro: Los cuantificadores anidados ([a-zA-Z0-9_\\-\\.]+)+ crear retroceso exponencial. Para un correo electrónico como aaaaaaaaaaaaaaaaaaaaaaaaa!, el motor de expresiones regulares intenta innumerables combinaciones antes de fallar. La expresión regular de URL tiene múltiples cuantificadores anidados que agravan el problema, haciéndola trivialmente explotable con entradas como cadenas largas de caracteres válidos sin la estructura esperada.

✅ Conforme:

function validateEmail(email) {
    const regex = /^[a-zA-Z0-9_\-\.]+@[a-zA-Z0-9_\-\.]+\.[a-zA-Z]{2,5}$/;
    return regex.test(email);
}

function extractURLs(text) {
    const regex = /https?:\/\/[\w\-]+\.[\w\-]+(?:[\w\-\.,@?^=%&:/~\+#]*)?/g;
    return text.match(regex);
}

Por qué es seguro: La eliminación de cuantificadores anidados elimina el backtracking catastrófico. Cuantificadores simples como [a-zA-Z0-9_\-\.]+ se ejecutan en tiempo lineal. El patrón de URL utiliza grupos no capturadores con sufijo opcional (?:...)? en lugar de repetición anidada, asegurando un rendimiento predecible independientemente de la longitud o el contenido de la entrada.

Conclusión

El rendimiento de las expresiones regulares es una preocupación de seguridad, no solo una optimización. Revise todos los patrones regex en busca de cuantificadores anidados, clases de caracteres superpuestas en grupos de repetición y alternativas ambiguas. Pruebe los patrones regex con entradas patológicas (cadenas largas de caracteres válidos seguidas de terminaciones inválidas) para identificar el backtracking catastrófico antes de la implementación. Cuando sea posible, reemplace las regex complejas con funciones de análisis de cadenas que tengan características de rendimiento predecibles.