Closed anakles closed 11 months ago
it looks to me like an indentation problem, the "if not ..." should be under "given request"
You are right, I've edited the example. However, this does not change the behavior, as described on the official page.
Hi
Indentation does not make a difference to the running of a BCheck, although it does help for easier readability.
Once a BCheck has found an issue, the BCheck will terminate.
We're gathering feedback on features that will be important for the next iteration of the BChecks language, and this functionality has cropped up a couple of times. We'll register your interest in this feature to help us decide where to focus on with BChecks in the future.
If there's anything else we can help with, then please let us know.
after thinking about it, I am having a similar issue related to that.
Say I am working on the endpoint /graphql
, and a report is already made. no more issue would be revealed in case the body (query mutation) is different !?
you can add this keyword
report [one / many] issue:
Hi
We just wanted to let you know that the latest version of the BChecks language (v2-beta, currently available in the latest Early Adopter version) includes report issue and continue
https://portswigger.net/burp/documentation/scanner/bchecks/bcheck-definition-reference#actions
Hi
We just wanted to let you know that the latest version of the BChecks language (v2-beta, currently available in the latest Early Adopter version) includes
report issue and continue
https://portswigger.net/burp/documentation/scanner/bchecks/bcheck-definition-reference#actions
Thank you for the update, Where i can found all the new language updates ?
regards
The BCheck definition reference page has been updated to include all the latest options.
Issue: Currently a BCheck will terminate, after an issue was created, regardless if there are
run for each
items that were not iterated yet. This behavior is counterproductive to me. I'd like to see BChecks that can create multiple issues, depending on certain conditions.Example: Consider the following scenario. I've created a BCheck that checks different supported / accepted content types for an API endpoint. I've created the following BCheck to replace the header 'Accept' with a value from a list of possibly supported content types. At the end, the BCheck verifies, whether the HTTP status code indicates, that the content type was accepted or not. In case it was, I want to create an issue for further, manual investigation.
Now if during the run of this BCheck this condition would equal true (e.g for
application/json
), Burp would no longer check, ifapplication/xml
is also accepted.Enhancement: I would like to see the BCheck continue after creating the first issue. In the mentioned example this would mean, that Burp creates an issue for both
application/json
andapplication/xml
(if accepted).