security for http headers

Question

We'd like to double-check our http headers for security before we send them out. Obviously we can't allow '\\r' or '\\n' to appear, as that would allow content injection.

I see just two options here:

1. Truncate the value at the newline character.
2. Strip the invalid character from the header value.

Also, from reading RFC2616 , it seems that only ascii-printable characters are valid for http header values Should also I follow the same policy for the other 154 possible invalid bytes?

Or, is there any authoritative prior art on this subject?

Answer 1

This attack is called "header splitting" or "response splitting" .

That OWASP link points out that removing CRLF is not sufficient. \\n can be just as dangerous.

To mount a successful exploit, the application must allow input that contains CR (carriage return, also given by 0x0D or \\r) and LF (line feed, also given by 0x0A or \\n)characters into the header.

(I do not know why OWASP (and other pages) list \\n as a vulnerability or whether that only applies to query fragments pre-decode.)

Serving a 500 on any attempt to set a header that contains a character not allowed by the spec in a header key or value is perfectly reasonable, and will allow you to identify offensive requests in your logs. Failing fast when you know your filters are failing is a fine policy.

If the language you're working in allows it, you could wrap your HTTP response object in one that raises an exception when a bad header is seen, or you could change the response object to enter an invalid state, set the response code to 500, and close the response body stream.

EDIT:

Should I strip non-ASCII inputs?

I prefer to do that kind of normalization in the layer that receives trusted input unless, as in the case of entity-escaping to convert plain-text to HTML escaping, there is a clear type conversion. If it's a type conversion, I do it when the output type is required, but if it is not a type-conversion, I do it as early as possible so that all consumers of data of that type see a consistent value. I find this approach makes debugging and documentation easier since layers below input handling never have to worry about unnormalized inputs.

When implementing the HTTP response wrapper, I would make it fail on all non-ascii characters (including non-ASCII newlines like U+85, U+2028, U+2029) and then make sure my application tests include a test for each third-party URL input to makes sure that any Location headers are properly %-encoded before the Location reaches setHeader , and similarly for other inputs that might reach the request headers.

If your cookies include things like a user-id or email address, I would make sure the dummy accounts for tests include a dummy account with a user-id or email address containing a non-ASCII letter.

Answer 2

The simple removal of new lines \\n will prevent HTTP Response Splitting . Even though a CRLF is used as a delimiter in the RFC, the new line alone is recognized by all browsers.

You still have to worry about user content within a set-cookie or content-type . Attributes within these elements are delimited using a ; , it maybe possible for an attacker to change the content type to UTF-7 and bypass your XSS protection for IE users (and only IE users). It may also be possible for an attacker to create a new cookie, which introduces the possibility of Session Fixation.

Answer 3

Non-ASCII characters are allowed in header fields, although the spec doesn't really clearly say what they mean; so it's up to sender and recipient to agree on their semantics.

What made you think otherwise?