Added BCheck scripts (x5)

[brumensywh]

BCheck scripts

• template-injection The script preform basic template injection attacks. It uses a prefix and a suffix that makes it possible to detect a potential blind-based template injection.

• waf-bypass For each new target detected, a dummy GET parameter is added to the URL with an included payload that tries to bypass the firewall the target is using (by default, only XSS payloads is given).

• path-bypass When a restricted endpoint is detected (not firewall-based), the script tries various techniques to bypass the restricted endpoints by adjusting the URL path.

• server-detect Simply look for common response headers that can reveal which server is used by the target.

• backend-language Simply look for file extensions in the response body to detect possible backend language used by the target.

Included CWEs

• waf-bypass.bcheck - Protection mechanism failure - CWE-693
• template-injection.bcheck - Improper Neutralization of Special Elements Used in a Template Engine - CWE-1336
• path-bypass.bcheck - Authentication Bypass Using an Alternate Path or Channel - CWE-288
• server-detect.bcheck - Exposure of Sensitive System Information to an Unauthorized Control Sphere - CWE-497

Others

• backend-language.bcheck - Detection of possible programming language used by the backend (recon)

Submission Guidelines

• [ ] Link to the primary research
• [x] All metadata fields are completed
• [x] BCheck is syntactically valid
• [x] BCheck is formatted correctly (4 spaces)

---

Feel free to give feedback and/or edit the script if necessary!

Regards, Brumens

[PortSwiggerWiener]

Thanks for all the updates 👍 . Do you want to move the waf-bypass to a separate PR and we can merge the others?

[brumensywh]

Yes, I can make a new pull request just for the waf-bypass BCheck script if you prefer. Do you want it in another folder or something else added to it?

[PortSwiggerWiener]

I think that the other scripts are good to go, but we still need to consider adding some initial WAF detection to the waf-bypass script. Currently it will raise an issue if the app ignores the payloads and returns a non-403 status code.

[brumensywh]

Yes, if it ignores the payload it will also be an indication that the WAF did not trigger, resulting in a successful bypass. I'm not sure it needs any initial WAF detection, I used it for a while and it has never been a problem all the time it has reported to the dashboard it has always been correct and the payload is indeed bypassing the WAF without any issues.

In case you still want some initial, what kind of initial would you like to see?

[Hannah-PortSwigger]

Yes, if it ignores the payload it will also be an indication that the WAF did not trigger, resulting in a successful bypass. I'm not sure it needs any initial WAF detection, I used it for a while and it has never been a problem all the time it has reported to the dashboard it has always been correct and the payload is indeed bypassing the WAF without any issues.

In case you still want some initial, what kind of initial would you like to see?

On testing the WAF Bypass BCheck against our vulnerable website, https://ginandjuice.shop, the issue triggered. In this case, there is no WAF to bypass, meaning that this is a false positive.

For now, could you split this file out from the others, so that we can merge the other files into the repo. After that, you can add some additional context to this BCheck.

We've checked with our researchers, and we like the concept of this BCheck. However, as there is no initial verification that the initial response should be a 403 (indicating that there is a WAF present), it is likely that when used generally this BCheck will generate a lot of false positives.

[brumensywh]

I get your point! Yes I can add that feature and separate the commit for you