PortSwigger / BChecks

BChecks collection for Burp Suite Professional and Burp Suite Enterprise Edition
https://portswigger.net/burp/documentation/scanner/bchecks
GNU Lesser General Public License v3.0
606 stars 107 forks source link

Improve "run for each" variables logic #31

Open Sh1Yo opened 1 year ago

Sh1Yo commented 1 year ago

When the run for each variables are used, the requests are getting repeated even though run for each placement may not be reached.

Consider the following situation:

You want to check for xss vulnerabilities. You have 10 payloads in run for each. But before sending those payloads you need to make sure that the injection point reflects on the page to decrease the amount of useless requests.

Example:


metadata:
    language: v1-beta
    name: "Test"
    description: "Tests"
    author: "sh"

run for each:
        calculation = "314116790-1", "314116788+1"

define:
    answer="314116789"

given insertion point then
        # check whether the injection point reflects on the page
    send payload: #[1]
        replacing: {answer}

        # if reflects - send payloads
    if {answer} in {latest.response} then
        send payload:  #[2]
            replacing: {calculation}

        if {answer} in {latest.response} then
            report issue:
            severity: medium
            confidence: tentative
            detail: "v"
        end if
    end if

With this configuration for every #[2] request the #[1] one will be sent as well(even if the first condition won't be reached at all), but the #[1] request needs to be sent only once because the response won't change.

I think it can be solved by adding another special word that will annotate the start of repeating for run for each . For example:

if {answer} in {latest.response} then
    repeat calculation:
        send payload:  #[2]
        replacing: {calculation}
A-J-C commented 1 year ago

Yes, currently the run for each will always repeat the whole check.

We would need to introduce a more advanced looping syntax for this use case. I'll keep this issue open to track the need for this feature.