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

Burp Suite User Forum

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

SUPPORT CENTER DISCORD

BCheck: Control HTTP Protocol (HTTP/1.0)

Paul | Last updated: Jul 24, 2023 03:22PM UTC

I've written a BCheck checking for IIS exposing internal IP addresses. The request is sent to certain locations and must be sent using HTTP/1.0 with no host header. I have the variable "potential_path" set to known locations for finding this issue. I use a raw request that looks like: given request then send request called root: `GET {potential_path} HTTP/1.0 ` However, when the BCheck runs, it sends everything correctly except it sends it using HTTP/2. For example, one of the potential paths is the "/". This is the request sent to target. (Line numbers included to demonstrate the request sends the correct new lines, it just isn't sending it has HTTP/1.0. 1| GET / HTTP/2 2| 3| I verified the finding on my current target server using Repeater. How I should write the check in order to use HTTP/1.0? Thank you.

Hannah, PortSwigger Agent | Last updated: Jul 25, 2023 03:54PM UTC

Hi

We've tested this out with the following BCheck script, and the requests are being issued unmodified when viewed through Logger

Could you confirm this is the case?

metadata:
    language: v1-beta
    name: "Test"
    description: "Lorem ipsum dolor sit amet"

define:
 potential_path= "/hello"

given request then
 send request called root:
  `GET {potential_path} HTTP/1.0

`

Paul | Last updated: Jul 25, 2023 04:45PM UTC

I am using Linux v2023.7.1 starting today, I was on the previous stable version before today, but I'm seeing the same result. I copy and pasted the code above into a new BChecks. When I view logger, I'm seeing the request as: 1| GET /hello HTTP/2 2| 3| I tested it against more servers and saw it sent HTTP/1.0 when the base target request was HTTP/1.1. Further testing showed disabling the setting "Default to HTTP/2 if the server supports it" under Network -> HTTP -> HTTP/2 made it work as expected so that my requests were sent using HTTP/1.0. Can that be confirmed? And if so, is that expected behavior. I expected the raw request in BChecks to supersede any other setting in Burp. Thank you.

Michelle, PortSwigger Agent | Last updated: Jul 26, 2023 01:16PM UTC

Thanks for the update. The Network -> HTTP -> HTTP/2 > "Default to HTTP/2 if the server supports it" should not affect how the request for your BCheck is sent. Can you tell us more about the test you're running when you see this behavior? Are you right-clicking the request in Repeater and choosing 'Scan' (to speed up the test, you can choose to use the 'Audit checks - Bchecks' only audit configuration) or have a custom Live Task configured so that requests sent using the Repeater tool are audited?

Paul | Last updated: Jul 28, 2023 04:42PM UTC

I am using a configuration to only do Bchecks and only have my Bcheck checked. I've tried to use right-click from proxy on an intercepted request, from Repeater, and from Intruder. All selecting to scan using the Bchecks only configuration. I get the same results for all attempts in viewing Logger for the requests. Off-topic, but the Invisible Recaptcha system is hit and miss with most of my submits being rejected with "Unable to verify you via Invisible Recaptcha, please try again". This happens across multiple browsers, computers, and IPs. This has taken over 2 days to post.

Michelle, PortSwigger Agent | Last updated: Jul 31, 2023 07:46AM UTC

Hi Thanks for getting in touch via email, we'll be in touch with an update soon

Michelle, PortSwigger Agent | Last updated: Jul 31, 2023 02:48PM UTC