On 31 Oct 2019, at 18:55, Richard Backman, Annabelle
<[email protected]> wrote:
>
>
> Relying on a fixed, random header name for security, even as a “defense in
> depth” measure, is dangerous. In order for this mechanism to be effective,
> the header name must be random (in the cryptographic sense) and must be kept
> secret. It needs to be withheld from request logs or error logs, either on
> the reverse proxy or on the service. It cannot be committed to code
> repositories.
Just like any other bearer token. I mean this is the *OAuth* WG, right? Where
we regularly recommend people send bearer tokens in headers? I don’t really
understand how that can be considered secure to send over the internet to a
cloud service, but suddenly becomes insecure when done inside the firewall
within a datacenter between a reverse proxy and an app server.
I mean, are people honestly suggesting that randomizing header names introduces
*new* vulnerabilities that aren’t present when you use a well-known name?
“Dangerous” even!
> Including it as a signed header in request signing algorithms that require an
> explicit list of signed headers (such as AWS Signature Version 4,
> draft-cavage-http-signatures, draft-ietf-oauth-signed-http-request) turns
> that signature metadata into a secret, meaning that it cannot be logged, etc.
> If signatures are sent to a central authority for processing, that authority
> must also know not to log the list of signed headers. I could go on, but I
> hope this is enough to express that there are SO MANY ways that header names
> can and will be revealed, and they aren’t always obvious.
>
> What we are talking about is a message authenticity problem. The best
> practices for providing message authenticity involve applied crypto, e.g., an
> HMAC or digital signature over the header contents. If an implementation does
> that, then the random header name is unnecessary. This approach is immune to
> the sort of misconfiguration scenarios that have been discussed in this
> thread, as they would result in the reverse proxy failing to provide a
> properly signed header to the service.
I agree that HMAC signatures are generally better, but which reverse proxies
support signing headers?
Actually HMAC signatures do have one significant downside compared to using a
random header name - if you forget to validate the signature *nothing fails*.
If you mess up the name of a random header then your app doesn’t see any
credentials and fails noisily.
— Neil
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
