Re: [Unbearable] Dealing with header injection through reverse proxies

[Willy Tarreau <[e-mail]>]

Hi Eric,

On Mon, Jul 17, 2017 at 08:18:10AM -0700, Eric Rescorla wrote:
> i folks,
> 
> We had a discussion today in TOKBIND about handling security-sensitive
> indications in HTTP headers (this came up in the context of
> https://tools.ietf.org/html/draft-campbell-tokbind-ttrp-01).  The
> setting here is that you have a network with a TLS reverse proxy
> serving the origin server, and the TLS proxy is responsible for doing
> some security check and telling the server about it. E.g.,
> 
>     Client                    Proxy                     Server
> 
>     <--- TLS w/ client auth ---> <----- HTTP with cert --->
> 
> The client does TLS client authentication with the proxy and then
> passes the certificate to the back-end server in an injected HTTP
> header (e.g., X-Client-Certificate). In order for this to be secure,
> the proxy has to *strip* any security sensitive headers sent by the
> client. Otherwise, the client could inject their own headers that
> would appear to come from the proxy.
> 
> Obviously, this design doesn't fail safe if the proxy fails to
> strip the headers. One way in which this can happen is if you
> have a large network of load balancers fronting a server network
> and you somehow incompletely misconfigure either the servers
> or the proxies, so that a server which supports this mechanism
> ends up behind a proxy which does not (and hence does not strip
> the headers). So, it would be nice to do something better that
> wasn't too heavyweight, especailly as a general solution.
> 
> One natural design is simply to have a shared key between the
> proxy and the server. In that case, it's easy to demonstrate
> that the header is injected, as in [0][1]
> 
>    X-Client-Certificate: <key>, <certificate>
> 
> The obvious objection to this design is that it requires you to
> establish the shared key, and people were concerned about having to
> configure it into the proxy. I'm aware of a number of designs here:
(...)

What I've seen and used was slightly different :
  1) proxies unconditionally remove the header field
  2) proxies unconditionally add the new header field even with no
     certificate
  3) servers verify that there is exactly one header field

This way even if step 1 above fails (eg: usual typo in the rule needed
to strip the header field which nobody notices since nobody injects
such a field name), step 2 ensures that any injection will be detected
in step 3.

In my opinion, it's important to stick to simple principles that can
be troubleshooted and fixed in field. For example I've had to deal
with signed header fields in the past and it used to be a great pain
to debug for everyone involved, to the point that people undervalue
the extra security. Simply prepending a clearly visible static value
into a field could help without adding much hassle but that's more or
less where the realistic limit lies in my opinion.

Cheers,
Willy