Fälschung von Anfragen auf Serverseite

Las vulnerabilidades de falsificación de solicitudes del lado del servidor se producen cuando un usuario puede hacer que una aplicación realice solicitudes HTTP a un dominio determinado por el atacante. Si una aplicación tiene acceso a redes privadas o internas, un atacante también podría provocar que la aplicación realizara solicitudes a servidores internos.

Analizaremos esto más de cerca con algunos ejemplos para entender mejor cómo se ve en acción.

Considere una API que toma una URL de un usuario y genera una imagen de la URL proporcionada por el usuario, por ejemplo, para obtener una vista previa o exportar una página.

ts
let url = request.params.url;

let response = http.get (url);
let render = response.render ();

devuelve render.export ();

Como el usuario controla el parámetro URL, permite al atacante acceder fácilmente a cualquier URL que desee. En algunos casos, según la biblioteca utilizada para acceder a la URL, pueden incluso tratarse de archivos locales que utilizan el esquema 'file: //'.

Una forma habitual de abusar de una vulnerabilidad de la SSRF, cuando está alojada en AWS, es utilizarla para acceder a la API de metadatos de AWS, que puede contener credenciales para la API de AWS. Esto puede conllevar un mayor acceso a otros recursos de AWS de la cuenta, lo que, como puede imaginar, no es lo ideal.

Mitigación

Mitigar las vulnerabilidades de la SSRF puede ser muy difícil a veces y depende en gran medida de lo que el código en cuestión intente lograr. En función de los requisitos, se pueden implementar diferentes medidas de mitigación.

Evite las URL determinadas por el usuario

En algunos casos, es posible que puedas implementar una función de forma que no dependa de que un usuario proporcione una URL arbitraria. Si esto es posible, es la forma más eficaz de mitigar el riesgo de la SSRF.

Minimice las capacidades

Si está implementando una función de exportación de PDF, es posible que se decante por utilizar simplemente un navegador sin interfaz y tomar una captura de pantalla de la página. Esto no siempre es recomendable, dada la complejidad de los navegadores y la gran cantidad de capacidades y superficies de ataque que exponen los navegadores.

Es importante utilizar la herramienta adecuada para el trabajo en cuestión. En algunos casos, bastará con un simple cliente HTTP. Siempre se pueden hacer cosas para minimizar las capacidades y, por lo tanto, la superficie o los vectores de ataque disponibles. Por ejemplo, en el caso de un cliente HTTP:

• Deshabilitar el seguimiento de los redireccionamientos
• Deshabilite todos los esquemas que no sean HTTPS

Hay algunos escollos

Redireccionamientos e iframes

Una forma habitual de protegerse contra la SSRF en los recursos privados (direcciones IP o nombres de host internos) consiste en analizar la URL proporcionada por un usuario y utilizar una «lista de denegación» para impedir el acceso a los recursos confidenciales.

Vale la pena señalar que este método no es efectivo en la mayoría de los casos, ya que se puede omitir en escenarios en los que el cliente sigue redireccionamientos HTTP, redireccionamientos HTML/JavaScript o puede renderizar elementos complejos como iframes.

Un atacante puede proporcionar una URL a una aplicación vulnerable que aloja una página que redirige a un recurso confidencial mediante un HTTP 301/302, una metaredirección de HTML, configurando la URL actual con Javascript al cargarse o incrustando un iframe que muestre un recurso interno. Esto evita de manera efectiva cualquier intento de validar la URL original.

Reenlace de DNS
También se puede realizar otro «tipo» de redireccionamiento a través del DNS. Una forma habitual de intentar prevenir los ataques de la SSRF es hacer lo siguiente:

1. Analiza la URL proporcionada
2. Toma el nombre de host y haz una búsqueda de DNS
3. Rechaza la URL si se convierte en una IP interna o privada, o acepta la URL si es una IP pública

Este método no es realmente efectivo debido a que es vulnerable a la «revinculación de DNS». La revinculación de DNS funciona debido al comportamiento estándar de la mayoría de las pilas de red (como las de Linux y Windows) cuando un host remoto cierra una conexión TCP.
Cuando un host remoto cierra forzosamente una conexión, intentará volver a conectarse después de realizar otra consulta de DNS para volver a resolver la dirección IP.

Esto permite al atacante hacer lo siguiente:

1. Crea una entrada DNS para `rebinding.attacker.com` con una dirección IP pública con un puerto HTTP abierto con un TTL (Time-to-Live) muy corto
2. Envía la URL (ejemplo: https://rebinding.attacker.com/) a la aplicación vulnerable. Comprueba que la IP resuelta no es privada, que no lo es, y luego continúa con la operación solicitada con la creencia de que es segura
3. Una vez que se establece la conexión HTTP, la entrada DNS de «rebinding.attacker.com» se cambia a una dirección IP interna
4. La conexión HTTP se cierra forzosamente
5. Esto ahora hace que la aplicación vuelva a resolver la dirección IP de «rebinding.attacker.com», que ahora apunta a una dirección IP interna
6. Como la protección por resolución de IP ya se ha producido y la reresolución de la entrada de DNS y la reconexión se producen en el núcleo, la aplicación no se da cuenta del hecho de que la IP ahora ha cambiado

Esto evita de manera efectiva la protección contra el suministro de URL que se resuelvan en direcciones IP privadas.

IPv4 frente a IPv6

Otra forma habitual de eludir cualquier «lista de denegación» es el uso de IPv6. Como todas las direcciones IPv4 se pueden expresar en términos de direcciones IPv6, con frecuencia es posible eludir las listas de denegación mediante el uso de una dirección IPv6 que también se asigne a una dirección IPv4 a la que se quiera acceder.