HTTP Response Splitting
The glory days of remote code execution exploitation are gone. Client side injection attacks have become today’s standard for attackers. The idea behind a client side injection attack is that the attacker is able to break out of an applications context to allow the execution of user provided data. The most familiar attacks of this class are: Cross-Site Scripting (XSS), Cross Site Request Forgery (CSRF), and SQL Injection. However, the theory of injection goes far beyond the inclusion of javascript or SQL in dynamic content. One of those less noticed attacks includes the HTTP Response Splitting attack (HRS). Although this attack was discovered in 2002, the security community still remains mostly aloof to its existence and exact mechanics [1]. Unfortunately this lack of knowledge leaves many to assume that such an attack is mostly harmless when compared to other attacks; in reality it is quite the opposite [4].
Overview
Normal HTTP traffic uses a one-to-one queue for request-response communication. The request agent will remember sending a single request and will expect a single response in return. Any additional responses are still added to the queue and remain there until the client is expecting a response. Because a queue is being used the first response in priority may not actually be the response associated with the most recent request [2]. An HRS attack exploits this functionality.
The attack involves three parties. The first of these parties is a vulnerable web server. The second party is the target; usually a web proxy or caching system. The third and final party is the attacker himself. When the appropriate environment exists, the attacker is able to alter a single request to appear and be processed by the web server as two requests. The web server in turn responds to each request. As those two responses return to the target, the cache/proxy will forward on the first response but will store the second one. As the agent submits another request the proxy will send the next response in the queue, which happens to be the response associated with the injected request. This can lead to a variety of attack vectors that will be discussed later.
How It Is Done
The vulnerability exists where user provided input is stored within the request’s HTTP headers. Lets use a simple redirect page as an example:
<?php header (“Location: “ . $_GET[‘page’]); ?>
This script will take whatever value is passed for the value of ‘page’ and use it within an HTTP header to redirect to a new page [4]. If I were to provide the value of ‘www.foobar.com’, the associated HTTP response would look as such:
HTTP/1.1 302 Found
Date: Wed, 16 Mar 2011 19:49:28 GMT
Server: Apache/2.2.17 (Unix) mod_ssl/2.8.27 OpenSSL/0.9.8o
Location: http://www.foobar.com
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
In such a situation the user’s browser would process this response and forward the user to the value of ‘Location:’. However, because the value of ‘page’ is not being scrubbed prior to being inserted into our HTTP header, it presents an opportunity for injection.
In order to manipulate the HTTP request we must understand the HTTP Protocol and its rules on the formatting of HTTP headers. The rule that relates to HRS is the specification of Carriage Return-Line Feeds (CRLF, or (\r\n). The use of CRLF in injection attacks has been around for some time [3]. It has been used to exploit many protocols and applications in order to bypass restrictions and manipulate data. In regards to HTTP, the protocol defines that each header will be separated with a single CRLF(\r\n), while the content will be separated from the headers by two CRLF(\r\n\r\n). Following these rules an attacker can inject a completely new request into the vulnerable header. Here is an example of an injection string, as it would look as a request to our redirect script:
http://www.vulnerablesite.com/redirect.php?page=nonsense%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2019%0d%0a%0d%0a<script>alert(/XSS/.source)</script>
Here we see that a normal looking request has been constructed using encoded values of the CRLF characters. The body of the response contains a XSS attack that is not limited as many other XSS attacks are. As the user submits their next request, the injected XSS response will be returned and executed in their browser [1].
Damage Potential
Cross-Site Scripting: This attack is what was demonstrated in our above examples. Essentially, the injected response could include any javascript code the attacker desires.[4]
Cross-User Defacement: This attack causes a defacement/spoofing type of condition on one specific user. This attack could be used in conjunction with other attack vectors to steal cookies and session data as well as other information about the user.[4]
Web Cache Poisoning: This attack is similar to Cross-User Defacement but instead it targets an entire group of users. It does this by poisoning the cache of a proxy that multiple systems communicate with and through. This causes the before mentioned exploited condition to be applied to multiple targets.[4]
Page Hijacking: The attacker can use this method to intercept the web server’s response to a users request. That request may contain important and private information that would now be sent to the attacker. [4]
Browser Cache Poisoning: This attack causes persistence of the defacement condition by forcing the browser to cache the targeted page.[4]
Mitigations
The primary mitigations against the HRS attack is two-fold. First, scrub user input of all CR & LF characters. Only insert them if you intend for them to be there. Secondly, check for encoded values and either escape them or sanitize them [4].
Conclusion
I hope that this has opened the eyes of the reader to better understanding injection theory, the vast scope of attacks that exist, and the importance of secure coding practices. I encourage the reader to go and do further research on the topics discussed here.
This is the article written by the discoverer of the HTTP Response Splitting attack. Readers should use this is an in depth reference to HRS in the real world. The author not only explains the attack and demonstrates its use, but also discusses evasion techniques that allow attackers to perform HRS upon targets with protection. The reader should grasp the full and indepth understanding of the danger and applications of the HRS attack in the real world.
This article gives a clear and concise breakdown of the HTTP Response Splitting attack. The theory and methodology of the attack is explained in a clear manner as well as explinations and examples. This article should serve as a means to allow the reader to grasp the overall idea behind HRS.
This article discusses the possibilities of the CRLF problem that make the HTTP Response Splitting attack possible. Not only does the author explain HRS, but he shows how abusing unfiltered input could allow him to create false log entries and other forms of manipulation. The reader should be able to understand the theory behind HRS and recognize other possibilities related to unfiltered CR-LF in all types of systems.
[4] Introdution to HTTP Response Splitting
This article talks more specifically about the different attack vectors that HTTP Response Splitting presents. The author gives exact examples to demonstrate each payload/vector in a clear manner. The reader should be able to conceptualize how the formation of an HRS attack would look like and therefore how to prevent it.
[5] OWASP: HTTP Response Splitting
This article is the official refernece for HTTP Response Splitting provided by the Open Web Application Security Project. This article is aimed towards the application developer. The information here gives a simple example of what a vulnerable target would look like and how a programmer would therefore be able to spot and mitigate the attack. After reading, the reader should be able to recognize a vulnerable target by looking at its request headers.
