Re: CVE-2025-0108

Can we agree that "X-Trust-Me-Bro: $boolean" headers set by reverse proxies are an anti-pattern?

If so, what is the best practice?

@buherator Just encode the data with a JWT.

(lest anyone take this seriously, I am shitposting here...)

@ryanc I was actually thinking whether some (not so) fancy crypto could be used to pass some instead of a bool that the attacker can't forge, then realized reverse proxy configs are not exactly designed to implement such transformations in the first place :)

Nonetheless, this is an illustrative example that unless we point to some robust solution ppl *will* come up with complex but insecure solutions (see also Schneier's Law).

@buherator JWT being a great complex insecure solution 😁

@ryanc X-Trust-Me-Bro: {"alg":"nOnE"...} vulns would be pretty funny actually :) let's hope we'll never get there though...

@buherator lulz driven development

@buherator @ryanc Like this?
https://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html

@buherator @ryanc HAProxy version https://www.haproxy.com/blog/verify-oauth-jwt-tokens-with-haproxy

@caspicat @ryanc No, the other way around: the proxy would generate a token based on a secret, so the value passed back to the app server can't be forged by the attacker.

But again: this would be in all likelihood a **BAD SOLUTION** because authn decision still would be made by a component that has incomplete information about exactly what should be authn'd and how! If you think about previous examples the rev proxy would generate a valid JWT just as it generated a True value because it interpreted the URL's differently than the app server.