2.3 - Header Injection

HTTP headers are dynamically generated and under certain circumstances user input may be injected. This can lead to false redirection, XSS, or HTTP response splitting.
HTTP request headers have a Referer, User-Agent (client software), and Cookie field, among others. Response headers for example have a status code, Cookie, and Location (redirection target URL) field. All of them are user-supplied and may be manipulated with more or less effort. Remember to escape these header fields, too. For example when you display the user agent in an administration area.
Besides that, it is important to know what you are doing when building response headers partly based on user input. For example you want to redirect the user back to a specific page. To do that you introduced a "referer" field in a form to redirect to the given address:
- What happens is that Rails puts the string into the Location header field and sends a 302 (redirect) status to the browser. The first thing a malicious user would do, is this:
- http://www.yourapp.com/some_controller/some_action?referer=http://www.maliciousstuff.tld
- a hacker may inject arbitrary header fields; for example like this:
- http://www.yourapplication.com/controller/action?referer=http://www.malicious.tld%0d%0aX-Header:+Hi! <http://www.yourapplication.com/controller/action?referer=path/at/your/app%0d%0aLocation:+http://www.malicious.tld>
- Note that %0d%0a is URL-encoded for \r\n which is a carriage-return and line-feed (CRLF - Carriage Return and Line Feed) in Ruby. So the resulting HTTP header for the second example will be the following because the second Location header field overwrites the first.
- So attack vectors for Header Injection are based on the injection of CRLF characters in a header field. And what could an attacker do with a false redirection? They could redirect to a phishing site that looks the same as yours, but ask to login again (and sends the login credentials to the attacker). Or they could install malicious software through browser security holes on that site. Rails 2.1.2 escapes these characters for the Location field in the redirect_to method. Make sure you do it yourself when you build other header fields with user input.
- If Header Injection was possible, Response Splitting might be, too. In HTTP, the header block is followed by two CRLFs and the actual data (usually HTML). The idea of Response Splitting is to inject two CRLFs into a header field, followed by another response with malicious HTML. The response will be:
```
HTTP/1.1 302 Found [First standard 302 response]
Date: Tue, 12 Apr 2005 22:09:07 GMT
Location:Content-Type: text/html

HTTP/1.1 200 OK [Second New response created by attacker begins]
Content-Type: text/html

&lt;html&gt;&lt;font color=red&gt;hey&lt;/font&gt;&lt;/html&gt; [Arbitrary malicious input is
Keep-Alive: timeout=15, max=100         shown as the redirected page]
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
```
Under certain circumstances this would present the malicious HTML to the victim. However, this only seems to work with Keep-Alive connections (and many browsers are using one-time connections). But you can't rely on this. In any case this is a serious bug, and you should update your Rails to version 2.0.5 or 2.1.2 to eliminate Header Injection (and thus response splitting) risks.
Allowing suspect requests to reach your code is not a best practice; you leave yourself open to all attacks you haven't yet heard of. Host header spoofing can cause very serious problems, and these attacks should be prevented. One popular and easy fix is to avoid the problem altogether by simply ignoring incoming requests that have suspicious host headers. In security speak, you want to ignore every request that comes in that has a host header that doesn't exactly match your system. In Nginx, this is done by setting up a default server on port 80 (and port 443 if you use HTTPS) that does nothing but return 444

server {
    listen 80 default_server;
    listen 443 default_server;
    return 444;
}

One issue with this is that some hosting solutions, like AWS, provide an automatic health/latency checking with a dynamic IP address in the host header. If you drop these requests, your instance will be dropped from your load balancer and you can't access your site from the web browser. You will need to put logic in your default server to pass these requests and ignore all others.

class ApplicationController < ActionController::Base
    before_action :debug_headers

	private
    def debug_headers
        if request.env['HTTP_X_FORWARDED_HOST']
            request.env.except!('HTTP_X_FORWARDED_HOST') # drop the variable
        end
    end

end

First, go to the URL of https://openedx.microsoft.com/ Later intercept the response of the particular URL using Burp suite Proxy Tool Spider the host to get the 302-redirect page and intercept the request with Burp suite Here I have changed the hostname from openedx.microsoft.com to bing.com in response the location is changed to https://bing.com
Later I captured the Burp suite response and opened it in a browser, the page gets redirected to the 404 response page of bing.com