Re: Attack research on HTTP/2 implementations

I think you could just as easily title that document "Request-Response Protocols Considered Harmful."


" 


Web developers are advised to shed assumptions inherited from HTTP/1. It's historically been possible to get away without performing extensive validation on certain user inputs like the request method, but HTTP/2 changes this.

"



To be expected (IMO) when major version numbers are tightly bound to a lower layer of the stack (/1 = TCP, /2 = SPDY, /3 = QUIC) when what I'd like to see is an HTTP spec (RFC) with generic language applicable to any underlying stack, otherwise what, /4 = SCTP anyone? Every time this happens, new assumptions are bound to be inherited, so to speak.



"There's too much confusion, I can't get no relief!"



An accompanying BCP covering input validation *and* sanitization would go a long way to avoiding common attack scenarios regardless of stack choice.



-Eric




---- On Thu, 05 Aug 2021 17:43:00 -0700 Martin Thomson <mailto:mt@lowentropy.net> wrote ----



https://portswigger.net/research/http2 
 
The introduction claims to have found imperfections in the RFC, so I read this fairly carefully.  There's solid work here in terms of attacking implementations, but no concrete specification problems. 
 
In terms of actual changes to specifications, the work we did in the HTTP/2 revision on field validation should already cover all of these attacks.  Not that RFC 7540 didn't, but we're a lot, lot clearer about it now. 
 
There's a lesson in here for our industry regarding how implementations deal with untrustworthy inputs.  The thing we might each reflect on is why we haven't already internalized that lesson.  It's not like this is a new class of attack or anything.