Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum will be discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Centre. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTRE DISCORD

Create new post

Paused-Based Desync Detection reporting HTTP/2 requests

Thomas | Last updated: Jan 08, 2024 08:22AM UTC

Hello! Burp Scanner's Client-Side desync check will sometimes report a firm status and confirm a paused-based desync vulnearbility. However. the attached requests on the issue, state that the requests are HTTP/2, which is a little confusing. See the below (I cannot give the actual target host I am afraid). I cannot attach images here so I guess text will do? Request 1: POST / HTTP/2 Host: redacted.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 Accept-Encoding: gzip, deflate, br Connection: keep-alive Content-Length: 332 Content-Type: application/x-www-form-urlencoded Request 2: GET /robots.txt HTTP/2 Host: redacted.com Accept-Encoding: gzip, deflate, br Accept: */* Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.6099.71 Safari/537.36 Connection: keep-alive Cache-Control: max-age=0 GET / HTTP/1.1 Host: redacted.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 Accept-Encoding: gzip, deflate, br Connection: close This does actually work using turbo intruder and HTTP/1.1. Its just confusing that I get HTTP/2 requests in the issue. Kind regards, Tom

Michelle, PortSwigger Agent | Last updated: Jan 08, 2024 02:57PM UTC

Thanks for taking the time to get in touch to report this. We have also replied to your email but here are the details: The developers have already been working on this scan check as we had scenarios where if Burp did not know whether or not the site supported HTTP/2, we were sending the requests that needed to be sent as HTTP/1, but these then got automatically upgraded to HTTP/2 because the server supports it. The updates for the scan check will be included in our next early Adopter release, so this should resolve your issue. I've linked this post to the bug report so we can let you know when there are updates, but please do keep an eye out for new releases on our Early Adopter channel. Please let me know if you have any questions.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.