* ¿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 & 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 de hacking** y hackear lo imposible - ¡**estamos contratando!** (_se requiere fluidez en polaco escrito y hablado_).
Cuando un navegador envía una solicitud a un servidor web, el servidor web responde con una respuesta que contiene tanto las cabeceras de respuesta HTTP como el contenido real del sitio web, es decir, el cuerpo de la respuesta. Las cabeceras 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 una nueva cabecera HTTP y cuándo termina otra. 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, incluyendo Apache, Microsoft IIS y todos los demás.\
En un ataque de vulnerabilidad de inyección de CRLF, el atacante inserta tanto el retorno de carro como los caracteres de avance de línea en la entrada del usuario para engañar al servidor, a la aplicación web o al usuario haciéndoles creer que se ha terminado un objeto y que ha comenzado otro. Por lo tanto, las secuencias de CRLF no son caracteres maliciosos, sin embargo, pueden ser utilizados con intenciones maliciosas, para la división de respuestas HTTP, etc.
En las 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 directa en 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.
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 se muestra a continuación:
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:
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 muestra:
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 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, 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á tratada por el servidor como un parámetro. Después de eso, hay otro & con el parámetro restrictedaction que será analizado por el servidor como otro parámetro. Efectivamente, esta sería la misma consulta que:
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. Esto 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.
El valor del encabezado se establece a través de un parámetro GET llamado "name". Si no se realiza ninguna codificación de URL y el valor se refleja directamente dentro del encabezado, es posible que un atacante pueda insertar 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 una carga útil XSS, por ejemplo:
Al explotar una inyección CRLF, un atacante también puede insertar encabezados HTTP que podrían usarse para derrotar mecanismos de seguridad como el filtro XSS de un navegador o la misma política de 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 [cross-site scripting (XSS)](https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/) que de otra manera no se podrían explotar.
Si un atacante puede inyectar los encabezados HTTP que activan CORS (Compartir recursos de origen cruzado), puede usar JavaScript para acceder a recursos que están protegidos por SOP (Política de mismo origen), que evita que los sitios de diferentes orígenes se accedan entre sí.
Al abusar de la inyección CRLF, puedes **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 nuevos encabezados y contenido del cuerpo**. Sin embargo, incluso puedes aprovechar esta vulnerabilidad para **inyectar una nueva solicitud HTTP**:
Puedes inyectar encabezados esenciales para asegurarte de que el **back-end mantenga la conexión abierta** después de responder a la solicitud inicial:
A continuación, **especifique una segunda solicitud**. Aquí tienes un [**ataque clásico** de **inserción de solicitudes**](http-request-smuggling/) con **encabezados/cuerpo adicionales** agregados por el servidor después de la inyección.\
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**.
Para obtener más información sobre esta técnica y los problemas potenciales, [**consulte la fuente original**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
Si una plataforma toma **datos de una solicitud HTTP y los utiliza 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, se utilizaron claves de caché 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 las IP y los puertos de los atacantes a usuarios cuyo correo electrónico el atacante no conocía:
**Para obtener toda la información, lee el** [**informe original**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/).
El impacto de las inyecciones de 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 mismo origen en los navegadores de la víctima, dejándolos susceptibles a ataques maliciosos.
La mejor técnica de prevención es no utilizar la entrada de los usuarios directamente dentro de los encabezados de respuesta. Si eso no es posible, siempre debes usar una función para codificar los caracteres especiales de CRLF. Otra buena práctica de seguridad de aplicaciones web es actualizar tu lenguaje de programación a una versión que no permita la inyección de CR y LF dentro de las funciones que establecen los encabezados HTTP.
Si estás interesado en una **carrera de hacking** y hackear lo imposible - ¡**estamos contratando!** (_se requiere fluidez en polaco, tanto escrito como hablado_).
* ¿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)
* **Ú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).
