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 headers and the actual website content. 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. They are also known as CRLF.
The server knows when a new header begins and another one ends with CRLF, which can also tell a web application or user that a new line begins in a file or in a text block.
What is CRLF Injection?
[Carriage Return Line Feed] CRLF Injection is a type of vulnerability that occurs when a user manages to insert a CRLF Injection into an application. The CRLF characters represent an end of line for many internet protocols, including HTML, and are %0D%0A which decoded represent \r\n. These can be used to denote line breaks and when combined with HTTP Request / Response Headers, can lead to different vulnerabilities, including HTTP Request Smuggling and HTTP Response Splitting.
This section will analyze two different attacks that target specific HTTP headers:
- • HTTP Splitting
- • HTTP Smuggling
1] HTTP Splitting
A successful exploitation of HTTP Splitting is greatly helped by knowing some details of the web application and of the attack target. For instance, different targets can use different meth-
ods to decide when the first HTTP message ends and when the second starts. Some will use the message boundaries, as in the previous example. Other targets will assume that different mes-
sages will be carried by different packets.
Others will allocate for each message a number of chunks of predetermined length: in this case, thesecond message will have to start exactly at the beginning of a chunk and this will require the tester to use padding between the two messages. This might cause some trouble when the vulnerable parameter is to be sent in the URL, as a very long URL is likely to be truncated or filtered. A gray box scenario can help the attacker to find a workaround: several application servers, for instance, will allow the request to be sent using POST instead of GET.
2] HTTP Smuggling
As mentioned in the introduction, HTTP Smuggling leverages the different ways that a particularly crafted HTTP message can be parsed and interpreted by different agents (browsers, web cach-
es, application firewalls). This relatively new kind of attack was first discovered by Chaim Linhart, Amit Klein, Ronen Heled and Steve Orrin in 2005.
There are several possible applications and we will analyze one of the most spectacular: the bypass of an application firewall.
In terms of HTTP Request Smuggling, this usually occurs when an HTTP request is passed through a server which processes it and passes it to another server, like a proxy or firewall. This type of vulnerability can result in:
• Firewall evasion, a situation where a request can be crafted to avoid security checks, typically involving CRLF Injection and overly large request bodies
• Request Hijacking, a situation where an attacker can steal HttpOnly cookies and HTTP authentication information. This is similar to XSS but requires no interaction between the attacker and client.
Now, while these vulnerabilities exist, they are difficult to achieve. I’ve referenced them here so you have an understanding of how severe Request Smuggling can be.
With regards to HTTP Response Splitting, attackers can set arbitrary response headers, control the body of the response or split the response entirely providing two responses instead of one as demonstrated in Example #2 – v.shopify.com Response Splitting (if you need a reminder on HTTP request and response headers, flip back to the Background chapter).
Twitter HTTP Response Splitting
Report Link: https://hackerone.com/reports/52042
Date Reported: April 21, 2015
Bounty Paid: $3,500
Good hacking is a combination of observation and skill. Knowing how encoded characters can be used to expose vulnerabilities is a great skill to have. %0D%0A can be used to test servers and determine whether they may be vulnerability to a CRLF Injection. If it is, take it a step further and try to combine the vulnerability with an XSS injection.
On the other hand, if the server doesn’t respond to %0D%0A think about how you could encode those characters again and test the server to see if it will decode the doubled encoded characters just like @filedescriptor did.
Be on the lookout for opportunities where a site is using a submitted value to return some type of header, like creating a cookie.