given query or body insertion point not working for Body paramters

[sA74n]

I have created bchecks for detecting sqli inj, but it seems to be appending the payload only on the GET parameters.

metadata:
    language: v1-beta
    name: "SQL Inj POST"
    description: "Tests for sqli"
    author: "Muthu"

run for each:
    inj = "'","'+OR+1=1--"

given query or body insertion point then
    send payload called check:
        appending: {inj}

    if {check.response.body} matches "(SQL|Postgresql|Microsoft Sql|sql|postgresql|microsoft sql)" then
        report issue:
            severity: info
            confidence: certain
            detail: `There is a change in response when {inj} is injected.`
            remediation: "Ensure your git directories are not exposed."
    end if

[Hannah-PortSwigger]

Hi

I've just tested running your BCheck against a request with both query parameters and body parameters, and the payloads get appended to both the query and body parameters in turn.

On the request that you are testing, is the issue found when modifying the query parameters?

Once an issue has been reported by a BCheck, the check will complete and will not continue past that point.

[sA74n]

Is it appending on every json value as well or appending the payload to whole json data?

[Hannah-PortSwigger]

Body parameters, unfortunately, do not include JSON insertion points. We have a feature request to include JSON parameters in BChecks, to which I have added your +1.

If you use "any" insertion points, then the JSON body will be used as an insertion point, but through testing, it looks like it appends to the entirety of the JSON data.

[Hannah-PortSwigger]

Reopening for better tracking of this feature request.

[lufeirider]

It seems that the bug has not been fixed so far. May I ask when the bug will be fixed?

[Hannah-PortSwigger]

@lufeirider Thank you for your message.

We do not currently have a time frame for when this enhancement work will be completed.

If there's anything else we can help with in the meantime, please let us know.

[SaeedHashem]

+1 here!

Great work on the BChecks guys, but that doesn't sound right! Some would argue JSON parameters are the most common type of body parameters nowadays. This missing isn't a missing feature, I'd say it's a straight up bug in the core functionality of the BChecks module. One would assume the insertion point type "any" == (query or body or cookie or header), but apparently that's not the case as body doesn't include JSON body parameters.

The current workaround of choosing "any" is fine for now, but it does add like a 100 unnecessary requests for each endpoint checked as most requests nowadays have like 10 cookies and headers on average.

[Hannah-PortSwigger]

Thanks for your interest, we've added your +1 to this feature request as well.

We do appreciate that it is confusing. Unfortunately, we don't have any other workarounds at this time, unless you'd prefer to write an extension-generated scan check.

[kenyon-wong]

+1 here!

Regarding the following POST request body:

{
    "startTime": "2023-09-19",
    "endTime": "2024-09-19",
    "pageSize": "100",
    "pageNum": "1",
    "pageType": "2"
}

Based on my testing, the following insertion point configurations are not functioning as expected:

• given query or body insertion point then
• given query insertion point then
• given body insertion point then

Note

By "not functioning", I mean that when testing in the Bchecks editor, no entries appear in the Logger panel.

While using given any insertion point then does work, it introduces two significant issues:

1. The payload insertion locations deviate significantly from the expected positions, particularly in areas I want to avoid (e.g., cookies)
2. The uncontrollable insertion positions make the packet inspection process extremely resource-intensive

Enhancement Suggestion:
If there isn't a concrete plan yet for handling value insertions in JSON fields, could we implement an exclusion mechanism for the any option? This would allow us to prevent fuzzing in specific locations, making the testing process more efficient and targeted.

[Hannah-PortSwigger]

Hi @kenyon-wong

Can you provide more information on what you mean by "not functioning"? It would be helpful if you could raise a separate issue for this or email us at [email protected].

We've added your +1 to this ongoing feature request. Unfortunately, we do not have any short-term plans to make any modifications to BChecks, but when we do come to make these changes, all feedback will be considered.