Subject: Core #30: HTTP Field Name Syntax

From: Mark Nottingham <[email-masked]>
Date: Mon, 15 Oct 2018 16:21:19 +1100

<https://github.com/httpwg/http-core/issues/30>

We discussed this in Montreal, and there seemed to be support in the room (and on the issues list) for restricting the characters available in HTTP headers to a more reasonable range.

The straw-man I put into the issue was:

1*( "-" / "_" / "." / "+" / DIGIT / ALPHA )

What do folks think about this?

If a server were to reject request headers that include characters outside this range, I think we'd be OK, since browsers don't produce such things (AFAICT; of course, we'd want to look into this more closely first).

I'd imagine that clients (especially browsers) would want to run some experiments first, and probably warn in the console, etc. before failing hard on this.

Thoughts?

Cheers,

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

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 15 Oct 2018 08:02:34 +0200

Hi Mark,

> What do folks think about this?

I totally support this. Right now haproxy only accepts the ones above in
addition to :

  "!" / "#" / "$" / "%" / "&" / "'" / "*" / "^" / "`" / "|" / "~" 

i.e. everything matching a token. Quite honestly, seeing any character from
this extra list in a field name would look extremely suspicious to me, and
I'd rather get rid of them.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 15 Oct 2018 08:25:08 +0200

> I'd imagine that clients (especially browsers) would want to run some experiments first, and probably warn in the console, etc. before failing hard on this.

I'm not convinced (but I could be).

What actual problem are we solving with that?

Do HTTP clients/servers currently reject illegal field names (do we have 
tests for that)? If they do not, why?

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 15 Oct 2018 06:26:47 +0000

--------
In message <[email-masked]>, Mark Nottingham wri
tes:
>We discussed this in Montreal, and there seemed to be support in the =
>room (and on the issues list) for restricting the characters available =
>in HTTP headers to a more reasonable range.
>

Unless there is normative us of it, I think we should leave out the
"." to protect OO languages from smuggling attacks.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 15 Oct 2018 10:43:45 +0200

Hi Julian,

> What actual problem are we solving with that?

I'd say that we limit the exposure on dirty servers. For example,
I've seen several times quickly implemented scripts basically doing

  $ eval "hdr_$name=$value"

By having '|', '`' and '$' there you see how dangerous this can be for
users who would never even imagine that the server they execute into
allow this.

> tests for that)? If they do not, why?

As I mentioned, haproxy does reject a lot of them. It once failed on an
application bug (application was placing '/' into header field names),
but the rest of the time these are attacks seen on the internet side.

I'm thinking that we could suggest something less extreme than blocking,
consisting in simply removing such header fields. If these ones are
placed by accident they will have no impact. If they are really needed,
the effect will be the same as if the header was rejected.

This would allow to distinguish between "forbidden characters" and
"unusual characters".

Regards,
Willy