HTTP Header Injection
HTTP header injection vulnerabilities arise when user-controllable data is inserted in an unsafe manner into an HTTP header returned by the application. If an attacker can inject newline characters into the header he controls, he can insert additional HTTP headers into the response and can write arbitrary content into the body of the response.
This vulnerability arises most commonly in relation to the Location and Set-Cookie headers, but it may conceivably occur for any HTTP header. You saw previously how an application may take user-supplied input and insert this into the Location header of a 3xx response. In a similar way, some appli- cations take user-supplied input and insert this into the value of a cookie. For example:
GET /home.php?uid=123 HTTP/1.1
Host: wahh-app.com
HTTP/1.1 200 OK
Set-Cookie: UserId=123
…
In either of these cases, it may be possible for an attacker to construct a crafted request using the carriage-return ( 0x0d ) and/or line-feed ( 0x0a ) characters to inject a newline into the header they control, and so insert further data on the following line. For example:
GET /home.php?uid=123%0d%0aFoo:+bar HTTP/1.1
Host: myapp.com
HTTP/1.1 200 OK
Set-Cookie: UserId=123
Foo: bar
…
Exploiting Header Injection Vulnerabilities
Potential header injection vulnerabilities can be detected in a similar way to XSS vulnerabilities, since you are looking for cases where user-controllable input reappears anywhere within the HTTP headers returned by the application. Hence, in the course of probing the application for XSS vulnerabilities, you should also identify any locations where the application may be vulnerable to header injection.
If it is possible to inject arbitrary headers and message body content into the response, then this behavior can be used to attack other users of the application in various ways.
Injecting Cookies
A URL can be constructed that sets arbitrary cookies within the browser of any user who requests it. For example:
GET /redir.php?target=/%0d%0aSet-cookie:+SessId%3d120a12f98e8; HTTP/1.1
Host: wahh-app.com
HTTP/1.1 302 Object moved
Location: /
Set-cookie: SessId=120a12f98e8;
If suitably configured, these cookies may persist across different browser sessions. Target users can be induced to access the malicious URL via the same delivery mechanisms that were described for reflected XSS vulnerabilities (email, third-party web site, etc.).
Delivering Other Attacks
Because HTTP header injection enables an attacker to control the entire body of a response, it can be used as a delivery mechanism for practically any attack against other users, including virtual web site defacement, script injection, arbitrary redirection, attacks against ActiveX controls, and so on.
HTTP Response Splitting
This is an attack technique which seeks to poison a proxy server’s cache with malicious content, in order to compromise other users who access the application via the proxy. For example, if all users on a corporate network access an application via a caching proxy, the attacker can target them by injecting malicious content into the proxy’s cache, which will be displayed to any users who request the affected page.
A header injection vulnerability can be exploited to deliver a response splitting attack using the following steps:
1. The attacker chooses a page of the application that he wishes to poison within the proxy cache. For example, he might replace the page at /admin/ with a Trojan login form that submits the user’s credentials to the attacker’s server.
2. The attacker locates a header injection vulnerability and formulates a request that injects an entire HTTP body into the response, plus a second set of response headers, and a second response body. The second response body contains the HTML source code for his Trojan login form. The effect is that the server’s response looks exactly like two separate HTTP responses chained together. Hence the name of the attack technique, because the attacker has effectively “split” the server’s response into two separate responses. For example:
GET/home.phpuid=123%0d%0aContentLength:+22%0d%0a%0d%0a<html>%0d%0afoo%0d%0a</html>%0d%0aHTTP/1.1+200+OK%0d%0aContentLength:+2307%0d%0a%0d%0a<html>%0d%0a<head>%0d%0a<title>Administrator+login</title>0d%0a[…long URL…] HTTP/1.1
Host: wahh-app.com
HTTP/1.1 200 OK
Set-Cookie: UserId=123
Content-Length: 22
<html>
foo
</html>
HTTP/1.1 200 OK
Content-Length: 2307
<html>
<head>
<title>Administrator login</title>
…
3. The attacker opens a TCP connection to the proxy server and sends his crafted request followed immediately by a request for the page to be poisoned. Pipelining requests in this way is legal in the HTTP protocol:
GET http://wahh-app.com/home.php?uid=123%0d%0aContent-Length:+22%0d
%0a%0d%0a<html>%0d%0afoo%0d%0a</html>%0d%0aHTTP/1.1+200+OK%0d%
0aContent-Length:+2307%0d%0a%0d%0a<html>%0d%0a<head>%0d%0a
<title>Administrator+login</title>0d%0a[…long URL…] HTTP/1.1
Host: wahh-app.com
Proxy-Connection: Keep-alive
GET http://wahh-app.com/admin/ HTTP/1.1
Host: wahh-app.com
Proxy-Connection: Close
4. The proxy server opens a TCP connection to the application, and sends the two requests pipelined in the same way.
5. The application responds to the first request with the attacker’s injected HTTP content, which looks exactly like two separate HTTP responses.
6. The proxy server receives these two apparent responses, and interprets the second as being the response to the attacker’s second pipelined request, which was for the URL http://wahh-app/admin/ . The proxy caches this second response as the contents of this URL. (If the proxy has already stored a cached copy of the page, the attacker can cause it to re-request the URL and update its cache with the new version by inserting an appropriate If-Modified-Since header into his second request and a Last-Modified header into the injected response.)
7. The application issues its actual response to the attacker’s second request, containing the authentic contents of the URL http://wahh-app.com/admin/ . The proxy server does not recognize this as being a response to a request that it has actually issued, and so discards it.
8. A user accesses http://wahh-app/admin/ via the proxy server and receives the content of this URL which was stored in the proxy’s cache. This content is in fact the attacker’s Trojan login form, so the user’s credentials are compromised.
Preventing Header Injection Vulnerabilities
The most effective way to prevent HTTP header injection vulnerabilities is to not insert user-controllable input into the HTTP headers returned by the application. As you saw with arbitrary redirection vulnerabilities, there are usually
safer alternatives available to this behavior.
If it is considered unavoidable to insert user-controllable data into HTTP headers, the application should employ a twofold defense-in-depth approach to prevent any vulnerabilities arising:
■ Input validation — The application should perform context-dependent validation of the data being inserted, in as strict a manner as possible. For example, if a cookie value is being set based on user input, it may be appropriate to restrict this to alphabetical characters only, and a maximum length of six bytes.
■ Output validation — Every piece of data being inserted into headers should be filtered to detect potentially malicious characters. In practice, any character with an ASCII code below 0x20 should be regarded as suspicious, and the request should be rejected. Applications can prevent any remaining header injection vulnerabilities from being used to poison proxy server caches by using HTTPS for all application content.
NEXT is..Frame Injection………………………………,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
