@angular/platform-server: Redirección abierta mediante URLs relativas al protocolo en Server-Side Rendering (SSR)

Se ha identificado una vulnerabilidad de redirección abierta (open redirect) en @angular/platform-server cuando Server-Side Rendering (SSR) está habilitado.

Cuando Angular SSR procesa una solicitud entrante, la resolución de URLs y la navegación de la plataforma son gestionadas por ServerPlatformLocation utilizando resolveUrl (o parseUrl en v20). Aunque resolveUrl rechazaba URLs relativas al protocolo cuya cadena cruda comenzara directamente con //, esta validación se ejecutaba antes de la normalización de URLs de WHATWG.

Cuando una URL de solicitud incluye un segmento de punto de retroceso seguido de múltiples barras diagonales (como /.//evil.test o serializado desde estructuras de rutas del enrutador como /.;/(//evil.test)), la entrada eludía la comprobación inicial de urlStr.startsWith('//'). El análisis posterior mediante WHATWG URL resolvía los segmentos de punto y daba como resultado un pathname que comenzaba con // (//evil.test).

En consecuencia, ServerPlatformLocation almacenaba pathname = '//evil.test'. Cuando @angular/ssr detectaba una discrepancia entre la URL renderizada y el estado final de ubicación del enrutador, emitía la ruta no normalizada en la cabecera de respuesta HTTP Location, produciendo una redirección HTTP 302 con Location: //evil.test, que los navegadores resuelven como una navegación relativa al protocolo fuera del origen.

Impacto

Una explotación exitosa permite a un atacante remoto no autenticado crear URLs que inducen a Angular SSR a redirigir a los usuarios a un dominio externo arbitrario.

• Evade guardas a nivel de aplicación: Las rutinas de validación comunes a nivel de aplicación (como comprobar !returnUrl.startsWith('//') antes de invocar router.navigateByUrl) aceptan /.//evil.test o /.;/(//evil.test) como una ruta relativa segura, permitiendo a los atacantes eludir listas permitidas de redirecciones.
• Las aplicaciones SPA de cliente no están afectadas: Las aplicaciones Angular puramente del lado del cliente (Single Page Applications sin SSR) no son vulnerables, ya que ServerPlatformLocation solo se utiliza en entornos de ejecución del lado del servidor.

Condiciones previas del ataque y configuraciones vulnerables

Una aplicación se ve afectada si se cumplen las siguientes condiciones:

• SSR habilitado: La aplicación se ejecuta en un entorno de Server-Side Rendering usando @angular/platform-server y @angular/ssr.
• Estructuras de rutas con parámetros: El enrutador contiene rutas parametrizadas con comodines o segmentos secundarios (por ejemplo, /:tenant que coincide con . y serializa grupos de salidas secundarias (//evil.test) a /.//evil.test), o pasa destinos de navegación suministrados por el usuario (por ejemplo, returnUrl).
• Paso a través del proxy inverso: Los proxies inversos upstream (Nginx, Cloudflare, ALB) reenvían puntos y comas (;) o segmentos de punto sin eliminarlos ni normalizarlos.

Ejemplo de carga útil de explotación

Un atacante envía una solicitud dirigida a una ruta con parámetros y segmentos secundarios:

GET /.;/(//evil.test) HTTP/1.1
Host: example.com

Respuesta:

HTTP/1.1 302 Found
Location: //evil.test

El navegador cliente resuelve //evil.test de manera relativa al protocolo y redirige al usuario fuera de example.com hacia evil.test.

Parches

El problema se resuelve actualizando resolveUrl (y parseUrl en v20) en @angular/platform-server para verificar que la ruta normalizada de la URL no comience con // cuando allowProtocolRelative sea false.

• 22.2.1
• 21.2.25
• 20.3.33

Mitigaciones y soluciones alternativas

Si no puede actualizar inmediatamente a una versión parcheada, aplique una de las siguientes mitigaciones en su proxy inverso perimetral o WAF:

1. Rechazar rutas con segmentos de punto seguidos de barras: Configure su proxy inverso (por ejemplo, Nginx, Cloudflare, AWS WAF) para bloquear solicitudes que contengan /.//, /..// o /.;/:
   nginx

   # Nginx example: reject suspicious path normalization sequences
   if ($request_uri ~* "(\n/\.\/|\/\.\;)") {
       return 400;
   }

2. Sanear cabeceras de redirección: Asegúrese de que los proxies perimetrales o pasarelas de API reescriban o no permitan cabeceras de respuesta Location relativas al protocolo (//) provenientes del servicio SSR upstream.