HTTP Response Splitting: A Common, But Frequently Unknown, Security Issue

[avatraxiom]

Recently, there were two security issues discovered in Bugzilla that would fall under the category of HTTP Response Splitting attacks. Although this is a common issue in web applications, many developers are unaware of it, its consequences, or how to protect their applications from it.

In short, here's what you need to know:

Never allow

Comments

Good one

[ext_21652]

You beat me to it :)

I am going to blog on a bunch of security issues I found in Google pages - and HTTP response splitting will make an appearance as well. But I am going to write something about how HTTP response splitting can be exploited in redirects.

I was actually pretty surprised to see this kind of vulnerability on google.com - unlike XSS it is easily solved on the API level, so it is typically only seen where web developers are simply ignorant. But ignorance is never the issue when we are talking about Google.

Re: Good one

[avatraxiom]

That sounds like it could be an interesting blog, for sure.

Yeah, honestly I think that it's just that a large number of developers really are ignorant about it. It's funny, people are aware of the problem when they put together RFC2822 emails, but for some reason they never think about it with HTTP headers--I think because they assume that their HTTP framework will "do the right thing" and convert or forbid the newlines. Even I wasn't aware of the problem until it was reported to us--I thought that CGI.pm would simply handle the situation properly instead of just allowing through all sorts of dangerous input.

-Max

Re: Good one

[ext_21652]

For whatever reason, PHP only fixed the problem in the framework only recently. CGI.pm does indeed escape newlines - but it doesn't look like they do it for security reasons (only some headers included and they don't look at LF). So I would say that the framework developers are largely ignorant.

Re: Good one

[avatraxiom]

Yeah. CGI.pm does it as of 3.50--we reported the issue to them and they released a fix. (They now die on invalid vertical whitespace in header values.) But before they were not doing it in a complete fashion.

I think that overall, what this vuln needs is a LOT more awareness in the developer community.

-Max

[ext_319473]

Yeah, and if for any reason you want to allow custom headers, make sure that the header name is something acceptable plus a colon, don't tolerate blank lines, and add at least one space and/or tab after every line break.

[avatraxiom]

Oh right, that's a good point too! I'm pretty sure header names are restricted to a pretty limited set of characters, so validating them against the RFC would be a good idea.

[ext_319473]

Oh, I suppose testing for /[A-Z][A-Za-z-]*:/, even if too lax, would be sufficient; but no space before the colon, and my point was: you can accept linebreaks if you add whitespace after each of them (to make "continuation" headers); and no empty lines (I'm not sure if a line containing one or more whitespace would terminate the headers, but there's no point in having them).

[avatraxiom]

Yeah, continuation headers are theoretically allowed, but I'm not aware of any single-line limit in any HTTP client or server anywhere (unlike with email), so I really don't think there's any point in supporting them.

-Max