Explicit HTTP/2 requests smuggling handling about tempesta HOT 4 OPEN

It seems this is a Burp issue. I retried the request with curl:

curl -i -v -k --http2 -H 'Content-Length: 9' -X POST --data 'abcd=dgdfGET /n HTTP/1.1\r\nHost: 02.rs?x.netflix.com\r\nFoo: bar' https://tempesta-tech.com

and I got

HTTP/2 400 
date: Sat, 18 May 2024 21:56:15 GMT
content-length: 0
server: Tempesta FW/0.8.0

with Warning: Request parsing inconsistency: 192.168.100.1 in log.

from tempesta.

OK, it seems we're good and do not pass any of the attack samples (I was playing with Burp and curl for the whole evening), but it's still worth checking our test suite for the attack samples and implement them in case of further regressions.

I'd be cool if you could break our protection against request smuggling attack.

Also please investigate the issue with Burp: maybe it was just a misuse on my side or the tool or Tempesta have some framing (I suppose) bug. If so then, the bug should be revealed and reported.

from tempesta.

On this screenshot Burp hangs in waiting for a response. Maybe there is a problem with the showing HTTP/2 as HTTP/1 feature...

from tempesta.

tfw_h2_parse_body() function does print Content-Length for debugging, but does not validate it against the actual DATA length. I played with varying the data length, but didn't succeed on request smuggling.

Looks like END_STREAM was not received. When END_STREAM is received tfw_h2_parse_req_finish() validates Content-Length against actual body length(total size of DATA frames), while END_STREAM not received Tempesta just waits next frame.

from tempesta.