Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
2  
None of your examples has got anything to do with protecting the server from malicious or otherwise unexpected data sent by the client (except perhaps cookie encryption, if that is indeed what you're doing). –  yfeldblum May 10 '12 at 5:43

2 Answers 2

up vote 4 down vote accepted

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.

share|improve this answer
1  
Thank you for this thorough response. I accepted your answer, but can't upvote it since I'm new to security.stackexchange (all my points so far are on SO). –  chowwy May 10 '12 at 0:45
    
+1 And @chowwy, good community spirit! –  msanford May 10 '12 at 3:14
1  
Now that I can upvote, it's upvoted! –  chowwy May 14 '12 at 15:38

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.

share|improve this answer
    
Thank you very much for this (I don't have enough points to upvote yet). A few things: I checked my framework's documentation and have found a way to setup validation for all user inputs; appreciate your advice on that. Also, I am already escaping queries, and user passwords are protected with bcrypt; users can reset passwords, but we don't send them out. And passwords have to be alphanumeric and 8 characters long. I have one other question on header injection, but I will put it in the next comment. –  chowwy May 10 '12 at 14:00
    
I don't understand where to check the headers for injection. I'm reading some tutorials on headers, and downloaded Live Headers in Firefox to see what comes up when I visit sites. I'm trying to figure out where header issues are dealt with in my application. –  chowwy May 10 '12 at 14:25
    
@chowwy: 1. For database queries: Don't escape SQL queries. Instead, use prepared statements. 2. For preventing header injection: you must validate all values that will ever be inserted into a HTTP header. You can validate these values at the entrance point to your code, as soon as you receive them. Validation should be written to ensure that the value doesn't contain anything that might be interpreted as a newline (and you might want to make it stricter, just in case). See MikeSamuel's answer for further information. –  D.W. May 10 '12 at 18:18
    
Okay, thanks. This is all useful info. Again, much appreciated. –  chowwy May 10 '12 at 20:23
    
Now that I can upvote, I've upvoted this. –  chowwy May 14 '12 at 15:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.