Re: Dealing with header injection through reverse proxies

Hey Patrick,

> If the problem can be reduced to the above then I think there are some http
> features that are worth considering if you're willing to look at it as a
> single hop requirement:
>
> a] if the proxy->server link is h1 then the x-client-certificate name can be
> included in the Connection header sent to the server (and the server can
> enforce this property). Any naive proxy receiving that same combination from
> a malicious client would remove the request-header of the same name before
> forwarding it on to the server and then generate its own Connection header.

This would work... but only in a single-hop deployments.

> b] if the proxy->server link is h2 then you can inject connection-specific
> information into the stream with an extension frame type (and the server can
> enforce this property). You don't need to negotiate it with SETTINGS (which
> is nice, because that's a round trip.) and these frames are hop to hop
> (proxies that don't understand a frame type MUST drop them).

Putting "internal" headers into a new HTTP/2 frame instead of mixing
them with client headers in the HEADERS frame is the idea that I've
been toying for a while now, mostly for multi-hop proxy deployments.

However, it's unclear whether the backend server should receive only
client headers (which wouldn't solve this particular issue) or both,
and how should this work with "internal" headers crossing
organizational boundaries (i.e. CDN terminating TLS and forwarding
"X-Client-Certificate" header to the origin server).

Also, this requires end-to-end HTTP/2, which is pretty much
non-existent nowadays, since most proxies don't support HTTP/2 to
backends (yet).

Having said that, this is something that I definitely want to see
done, regardless of whether it's the right solution for this
particular issue or not.

Best regards,
Piotr Sikora

Received on Tuesday, 18 July 2017 09:16:45 UTC