Reports
MEDIA[CONFIGURACIÓN]#3966599

AWS: instancias go-httpbin expuestas en *.aws.dev permitían plantar cookies en todo el dominio y redirigir a cualquier web

Varias instancias públicas de go-httpbin en subdominios de aws.dev dejaban fijar cookies con Domain=aws.dev, que llegaban a otras aplicaciones del dominio (llegando a bloquearlas por el WAF), y redirigir a cualquier URL.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

go-httpbin es una herramienta pensada para probar clientes HTTP: devuelve lo que se le pide, fija las cookies que se le indican y redirige adonde se le diga. Es útil en un laboratorio, pero el investigador encontró varias instancias publicadas sin autenticación en subdominios de aws.dev, un dominio que comparten muchas aplicaciones distintas de AWS.

Dos de sus funciones se podían aprovechar contra terceros:

  1. Cookie tossing (inyección de cookies entre subdominios). El endpoint /cookies/set deja elegir libremente los atributos de la cookie, incluido Domain. Basta con pedir Domain=aws.dev para que la cookie quede asociada al dominio padre y el navegador la envíe a cualquier otra aplicación *.aws.dev, aunque no tenga nada que ver con go-httpbin.
  2. Open redirect. El endpoint /redirect-to acepta cualquier URL en el parámetro url y responde con un 302 hacia ella, sin comprobar el destino.

El investigador comprobó que las cookies plantadas llegaban a aplicaciones ajenas del mismo dominio y que un valor concreto hacía que otra aplicación respondiera con un 403 de CloudFront/WAF a la víctima. Las direcciones exactas de las instancias y de la aplicación afectada están ocultas en el reporte publicado.

El programa (VDP de AWS) clasificó el fallo como de severidad media, con la debilidad "Missing Authentication for Critical Function". Se envió el 24 de agosto de 2026, figura como resuelto y se divulgó el 16 de octubre de 2026.

Pasos de reproducción

Open redirect

Una sola petición basta para ver que el servidor redirige a un dominio externo cualquiera (el host está oculto en el original):

$ curl -s ████████redirect-to?url=http://google.com -D - -o /dev/null
HTTP/1.1 302 Found
Server: ████████
Date: Mon, 24 Aug 2026 21:27:43 GMT
Content-Length: 0
Connection: keep-alive
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Location: http://google.com

$

La cabecera Location devuelve tal cual el valor del parámetro url.

Cookie tossing

  1. Abrir la aplicación víctima (otra web bajo *.aws.dev, sin relación con go-httpbin) y comprobar su comportamiento normal: responde 401 y muestra un formulario de inicio de sesión.
  2. En el mismo navegador, visitar la instancia vulnerable de go-httpbin con esta ruta, que fija la cookie dos_poc con el dominio padre aws.dev:
████████cookies/set?dos_poc=<script>alert(1)</script>&attr[Domain]=aws.dev
  1. Volver a la aplicación víctima. El navegador le envía ahora la cookie dos_poc (porque su dominio es aws.dev), y su valor, con aspecto de payload XSS, hace que CloudFront/WAF deniegue la petición con un 403. La víctima deja de poder acceder a esa aplicación mientras conserve la cookie.

El bloqueo afecta solo al navegador de quien ha visitado la URL de go-httpbin, no a todos los usuarios de la aplicación.

Impacto

  • Cookies plantadas en aplicaciones ajenas: cualquiera podía fijar cookies con alcance *.aws.dev que el navegador enviaría a aplicaciones hermanas sin relación con go-httpbin.
  • Denegación de servicio por usuario: con un valor que dispare las reglas del WAF, la aplicación víctima rechaza las peticiones de ese navegador con un 403.
  • Posible sombreado de cookies: una cookie del atacante con el mismo nombre que una de sesión o de seguridad de otra aplicación podría interferir con ella (el reporte lo plantea como posibilidad, no como algo demostrado).
  • Redirección abierta: una URL de apariencia legítima bajo aws.dev podía llevar a la víctima a un destino externo controlado por el atacante.

Remediación

El reporte figura como resuelto, pero no detalla la corrección aplicada.

Qué aprender de este caso

  • Las herramientas de depuración HTTP (httpbin, go-httpbin y similares) publicadas en un subdominio de un dominio compartido son muy útiles para un atacante: al hacer reconocimiento, busca rutas como /cookies/set o /redirect-to en los subdominios y mira si el servicio responde sin autenticación.
  • Si un endpoint deja escoger el atributo Domain de una cookie, el riesgo no es para ese host sino para todos los hermanos del dominio padre. Al revisar, prueba a fijar Domain con el dominio registrable (aquí aws.dev) y comprueba si la cookie llega a otras aplicaciones.
  • Un valor de cookie con aspecto de ataque (<script>…) puede bastar para que un WAF bloquee a un usuario: las aplicaciones detrás de un WAF que comparten dominio padre con servicios de prueba heredan esa denegación de servicio. Separar las aplicaciones no relacionadas en dominios distintos (o en dominios incluidos en la Public Suffix List) corta el problema de raíz.
  • Al desplegar, no expongas servicios de prueba en dominios compartidos con otras aplicaciones y, si hacen falta, ponlos detrás de autenticación.