header injection + codeigniter

Question

I'm reading through Mozilla's Secure Coding Guidelines, and found this statement:

Don't trust any user data (input, headers, cookies etc). Validate it before using it

I'm using the codeigniter framework, and am using the following (mostly built-in functions) for inputs and cookies:

Inputs

• global xss filtering is set to TRUE
• CSRF protection is set to enabled

Cookies

• cookies are flagged as secure
• cookies are flagged HTTPOnly
• cookies are encrypted

Headers. This is where I'm running into an issue. How do I protect my site against header injection? Haven't been able to figure this out.

Also, while I am validating user inputs like passwords, etc., am wondering if there is some other type of validation that needs to be done?

Answer 1

I use HTTP response header splitting as an example below, but the solution at the end works equally well when the injection is into the response content body.

For example, an attacker supplies an input

/
Access-Control-Allow-Origin: evil.org

and then the server uses that input to generate headers

response.setHeader("Location", input)

which results in the headers

 Location: /
 Access-Control-Allow-Origin: evil.org

One solution is to carefully check all code that specifies headers and make sure it does not use unfiltered/untrusted inputs to generate the headers. This is error-prone, time consuming, and is not guaranteed to hold under maintenance.

A more robust solution is to use library methods like response.setHeader that refuse inputs that contain newlines. If response.setHeader did

 void setHeader(String name, String value) {
   if (!(match(name,  "^[A-Za-z\\-]*\\z") &&
         match(value, "[^\u0020\u0021-\u0023-\u007f]*"))) {
     throw ...;
   }
   ... 
 }

then an attacker might be able to deny service, but would not be able to split headers, and your logs would contain traces pointing to the problematic setHeader call.

If you're using a framework, often you can wrap your response objects so that the header methods do this.

Answer 2

General. "Validate input before using it" means you must write code to check that the input is of the expected form (e.g., check it against a whitelist) before you use it. This is part of your responsibility when writing the code. You must do this everywhere that your code recieves inputs from untrusted sources.

Setting configuration flags (like global XSS protection or CSRF protection) is not a replacement for validating input before using it.

See, e.g., OWASP's guidelines for a lot more information about this subject.

Make sure you also read up about escaping of values before output.

Header injection. Check the value against a whitelist that is derived based upon the type of value you are expecting: e.g., every character in the input should be in a certain whitelist of allowable characters, or the input string should match some carefully constructed regexp. Make sure sure that your whitelist does not include any newlines or other control characters.

Passwords. There's not a lot of validation that makes sense. You might want to check that the password does not contain any '\0' (nul) bytes, just as a sanity check. Probably the first and only thing you should do with a password is immediately hash it (using bcrypt, PBKDF2, or scrypt), then never look at or use the cleartext password again. As long as you make sure to follow that pattern, probably no additional validation is needed.

If you ever send the password by email, check that the password does not contain newlines or other control characters. If you insert the password into a database, make sure to use SQL prepared statements to form the database query (don't use string concatenation). If you ever display the password on a web page by including it in dynamic HTML (probably a bad idea...), then make sure you HTML-escape the password properly before including it in the HTML.