Subject: Re: (issue 30) - concrete security-related examples

From: Mark Nottingham <[email-masked]>
Date: Tue, 21 Jul 2009 11:37:38 +1000

Hi Amit,

Just making sure we've closed the loop here:

On 12/09/2008, at 6:05 AM, Amit Klein wrote:

>
> LWS should not be allowed between the field name and the colon. See  
> the section 'The “Double CR in an HTTP header” technique (and the  
> “header SP” technique)' in http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf

p1 4.2:
No whitespace is allowed between the header field-name and colon. For  
security reasons, any request message received containing such  
whitespace MUST be rejected with a response code of 400 (Bad Request)  
and any such whitespace in a response message MUST be removed.

> Lone CR should not be allowed. See the section 'The “Double CR in an  
> HTTP header” technique (and the “header SP” technique)' in http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf 
>  (NOTE: we dubbed it "double CR" because it is part of a sequence CR 
> +CR+LF).

CRLF is specified, and the p1 A (Tolerant Applications) notes:
The line terminator for message-header fields is the sequence CRLF.  
However, we recommend that applications, when parsing such headers,  
recognize a single LF as a line terminator and ignore the leading CR.

> Invalid chars in field name: e.g. use of underscore for attack is  
> discussed in http://kuza55.blogspot.com/2007/07/exploiting-reflected-xss.html

Underscores are allowed in HTTP header field-names.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

---

From: Amit Klein <[email-masked]>
Date: Tue, 21 Jul 2009 13:11:20 +0300

Hi Mark et al.

Please see my comment inline.

Thanks,
-Amit

On Tue, Jul 21, 2009 at 4:37 AM, Mark Nottingham<[email-masked]> wrote:
>> LWS should not be allowed between the field name and the colon. See the
>> section 'The “Double CR in an HTTP header” technique (and the “header SP”
>> technique)' in http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
>
> p1 4.2:
> security reasons, any request message received containing such whitespace
> MUST be rejected with a response code of 400 (Bad Request) and any such
> whitespace in a response message MUST be removed.
>

Good.

>> Lone CR should not be allowed. See the section 'The “Double CR in an HTTP
>> header” technique (and the “header SP” technique)' in
>> http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf (NOTE: we dubbed
>> it "double CR" because it is part of a sequence CR+CR+LF).
>
> The line terminator for message-header fields is the sequence CRLF. However,
> we recommend that applications, when parsing such headers, recognize a
> single LF as a line terminator and ignore the leading CR.
>

OK.

>> discussed in
>> http://kuza55.blogspot.com/2007/07/exploiting-reflected-xss.html
>

In such case, wouldn't there be collisions, e.g. User-Agent and
User_Agent both will map into the CGI env variable HTTP_USER_AGENT.

---

From: "William A. Rowe, Jr." <[email-masked]>
Date: Tue, 21 Jul 2009 12:06:29 -0500

> User_Agent both will map into the CGI env variable HTTP_USER_AGENT.

That's not a concern of the http 2616 spec, but an issue for RFC3875.
Note that 4.1 of that RFC does not demand underscores, but illustrates
then and states that "A particular system can define a different
representation".

The obvious system is to invert the dash and underscore provided that
the system exposing these variables (e.g. environment tables on most
platforms) can represent dashes as well as underscores.

All of the symbols below are permitted as token, AIUI;

 "!" "#" "$" "%" "&" "'" "*" "+" "-" "." "^" "_" "`" "|" "~"

As well as all control codes 0 - 31 excluding 9, plus 127.  Of course
many of these make no sense, but that's the existing spec.  RFC2616bis
is not chartered to change the spec, only clarify it.

---

From: "William A. Rowe, Jr." <[email-masked]>
Date: Tue, 21 Jul 2009 12:17:23 -0500

> All of the symbols below are permitted as token, AIUI;

The above is correct, that's where my brain failed me...

<incorrect>
> is not chartered to change the spec, only clarify it.
</incorrect>

Momentary space-out there, sorry for the misinformation; of course...

token          = 1*<any CHAR except CTLs or separators>

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 21 Jul 2009 21:43:45 +0200

> Underscores are allowed in HTTP header field-names.

True, but the exploit is still very much valid. It's not an exploit on
HTTP as such but on a large family of specifications for running code on
HTTP servers (CGI, PHP, etc) as most those specs translate - to _ which
gets ambiguous when there is headers having _ in their name.

Which begs the question if this is sufficient grounds for banning the
use of headers using _ where there is standard track headers with the
same name using -

User-Agent is mentioned in the report, but I can imagine there is
interesting or at least disturbing tricks to be done using
Content-Length, Accept-* etc beyond the potential XSS issues the report
mentions, especially when there is caches involved and the resource in
question does some kind of content negotiation.

Regards
Henrik