Earlier quoted context omitted.
Glad you like the research! I'll look into emphasising the vector though I'm personally coming to the viewpoint that the root cause is a design flaw in HTTP/1.1, and HTTP/2 is the only truly reliable fix.
Thanks for the comments. I don't see that using HTTP/2 is realistic. (a) Are you saying that using HTTP/2 from the browser makes headers in your infrastructure secure? (b) Some of our enterprise clients use security proxies (e.g. Cisco WSA) which do not support HTTP/2 and force connections from the browser to use HTTP1.1. Aside: Cisco WSA is super crappy: we have recorded a repeatable corruption that passed informati…
Regarding HTTPS between the frontend and backend, remember that's just HTTP over a TLS stream instead of TCP. As long as the frontend still reuses these TLS streams, it's exploitable. To be clear, this is in a scenario where the front-end terminates the HTTPS connection from the client then routes requests over a pool of persistent HTTPS connections to the backend. Does that make sense? Since I've been exploiting this from a black-box perspective, I can't really tell for sure whether I've successfully exploited any websites actually doing this.
And yeah it would have been nice of this had done better on HN but between presenting it at two major security conferences and adding automated detection to a popular web scanner, it ought to achieve decent awareness over the next few months. Hopefully.