"Twitter is one of the most popular social media platforms available today, with 100 million daily active users and 500 million tweets sent daily. But, do they have the best cybersecurity defense? Youssef discovered It was possible to inject the CRLF injection vulnerability to HTTP response splitting in the endpoint https://ads.twitter.com/subscriptions/mobile/landing that allows to an attacker add a malicious header in the response headers.This vulnerability was spotted by Youssef on Twitter webapp and reported on hackerone.
Twitter was all in praise for this bug bounty. Now, let's understand this further so that we can avoid such vulnerabilities"
Web applications all over the digital world are full of security holes that can be used to get around security measures. One type of attack is an injection attack. We know that a web application has many injection vulnerabilities, such as SQL injection, HTML injection, CRLF injection, cross-site scripting, and many others. This article will talk in depth about the CRLF injection vulnerability and how it affects the security of web applications. Let's start with what it means.
What's the CRLF?
Carriage Return
Carriage return line feed is what CRLF stands for. ASCII 13 (\r) shows a carriage return, which means the end of a line. We use ‘\r’ to show that a line is over.
Line Feed
ASCII 10 (\n), which stands for "line feed," shows where a new line starts. We put '\n' at the beginning of a new line. If you write something after "n," it will start on a new line. CRLF characters are the ‘\n’ and ‘\r’ (cr and lf).
CRLF – Defined
When a user does anything on the internet, the web browser sends some requests to the web server. The web server responds to the browser's request with an HTTP response.
Some HTTP headers and the website content are part of the HTTP response. Here, the special CRLF characters come into play. They separate the headers from the actual content of the website in the HTTP response.
Carriage return line feed not only marks where a new HTTP header begins or ends, but it also tells the user where a line begins or ends in a file or a block of text.
The operating systems also use these CRLF characters. CR and LF are used to end lines in Windows, but only LF is used in UNIX/Linux. The CRLF character sequence is also used to end a line in the HTTP protocol.
What is a CRLF injection vulnerability?
The attacker attacks the web application by adding carriage return and line feed (cr and lf) through the user input area. With the CRLF injection attack, the web server or web application is tricked into thinking that the first object it was given has ended and another object has begun. Since CRLF characters were made to separate the HTTP headers from the web content, they are not meant to be harmful. But they can still be used as payloads for attacks that are meant to do harm.
The main reason for a CRLF injection attack is that the user's input is not sanitised before it is checked against a trusted source.
Injecting CRLF into a web application
In bugcrowd, CRLF injection in a web application is given a severity level of P3.
CRLF injection can further be escalated from information disclosure to Remote Code Execution. It can also lead to cross-site scripting attacks, poisoning of web caches, and many other things.
Impacts of CRLF injection:
Cross-site scripting:
The Web Application's protection against Cross-Site Scripting (XSS) can be gotten around by adding CRLF to the URL and putting an XSS payload in it using HTTP headers. Here, a URL-encoded value for CRLF is used to tell the browser where the request body starts and to put Cross-Site Scripting payload in it. A simple example was shown in below:
Request:
http://example-website.com/%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3csvgonload%3dalert%28document.domain%29%3e
Response:
Client-side Cookie Injection:
It is possible for an attacker to alter the cookie before it is transmitted to a web server, known as a Client-side Cookie Injection attack. This vulnerability can lead to Man-in-the-middle Cookie Hijacking, Session Forgery, Session Hijacking, etc.
A simple CRLF injection example is presented below:
Request:
https://example-website.com/session_start/%0aSet-Cookie: malicious_cookie1
Response:
HTTP Response Splitting:
When an attacker sends a single HTTP request and forces the Server to make two output Responses, this is called HTTP Response Splitting. The attacker might be able to change some parts of the first response, but what really matters is whether or not the attacker can change the entire second response, right down to the last byte of the HTTP response body.
Request:
http://example-website.com/url?=foobar%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContentLength:%2019%0d%0a%0d%0a
TEST
Response:
HTTP Header Injection:
When CRLF injection is used, HTTP header injection vulnerabilities can be opened up.
This can make it so attackers have to add or set their own HTTP custom headers to bypass the security measures like XSS filters or the same-origin policy. Attackers can also get confidential data, such as CSRF tokens, and set their own cookies. Attackers can bypass the security features of web apps this way.
If the attacker can inject HTTP headers like the "Access-Control-Allow-Origin" header, he can turn on cross-origin resource sharing and get the JavaScript codes that are protected by the "same-origin policy."
Now let's look at how to add HTTP headers to HTTP response headers. With the %0d %0a character, we can add a fake HTTP response header to the URL parameter. To add a fake HTTP response header, we will use a single CRLF. We will change the HTTP request as shown below,
Example:
GET /%0d%0aMy-Header: Header
If web applications have a CRLF injection vulnerability, the header will show up in the response headers and the other headers as well.
Preventing CRLF Injections:
- User input should be Sanitizated.
- Encode the CR and LF characters (\r, \n) so that the server can't read them even if they are sent.
- Validate the user input before they reach the response headers (example: by using methods like StringEscapeUtils.escapeJava()).
- A header that isn't needed should be disabled.
Summary:
Developers should be careful and aware that their platforms might have these kinds of flaws.
This will help them make an application that is safe. In terms of application security, the user input can't be trusted, so it needs to be checked before it can be used in the application. We need both good development practises and security methods to keep ourselves safe from threats in the world.
