Taking your web application pentesting to another level
By making use of Bchecks in Burp suite
Introduction
When doing a web application pentest Burp Suite is one of the go to tools.
A few weeks ago Portswigger released a new feature called Bcheck scripts. Which can be found in version 2023.6 and it is a very useful new feature.
In this article, I will tell you what BCheck Scripts are, how you can write them, and for what you should use them. It will help you speed up some parts of the testing methodology through simple scripting. But not all!
What are BCheck Scripts?
BCheck Scripts is a new extension for Burp Suite Professional. It is based on easy-to-write templates which makes them fast to write. The idea is that you create a simple script for a specific task. These different tasks will be used as part of your security testing methodology.
The template definition can be found here.
The script language is based on the: given then structure and if you have any basic programming experience it should be easy to implement. There already is a community providing bcheck scripts, which you can upload straight into burp suite.
These bcheck scripts run as part of an active scan can perform a few different tasks. They can help with:
- Performing host-based checks:
For example is there a security.txt hosted on the domain? or .git folder? - Performing response level checks: check the response data for example to find interesting secret keys.
- Performing insertion point checks: which will run on each insertion point.
- Performing collaborator checks: for example to test for SSRF?
These features allow you to automate many of the tedious tasks normally associated with Web/API security testing, such as validating inputs or checking for unexpected tokens in the response. This can help speed up your testing process significantly. But saves you from the time of writing a complete addon.
Benefits of BCheck Scripting
One of the major advantages of BCheck Scripts lies in its simplicity and efficiency. They are quicker and easier to write compared to custom BApp extension. Making them ideal for adding simple yet effective checks to your security scan. Additionally, BCheck Scripts allow for code reuse and maintainability, streamlining your security assessments. You can check out Portswigger’s GitHub repo to get a feel for what a BCheck script looks like.
I will go over my own made BCheck which can also be found in the github repo.
How to start writing your first .bcheck script
You can write your bcheck scripts directly in Burpsuite:
You can find it by following these steps:
- Clicking on the Extensions tab
- Clicking the BCheck subtab
- Clicking the New button

It will prompt you to select a BCheck template to use:

They contain some example scripts as well, which are useful to read!
The template I used for my SAP authentication bypass check was a Host-Level template which is the most basic one.
The Host-Level Bcode explained
Let us start with the following piece of code used for performing a check if the website is vulnerable to a SAP authentication bypass:
metadata:
language: v1-beta
name: "SAP authentication bypass check"
description: "Tests for Sap authentication bypass SAP Note 2258786 Checking if the public
endpoint of sap/admin/public is accessible which would leak the patch management and internal urls"
author: "Bob van der Staak"
tags: "SAP", "Authentication Bypass"
run for each:
potential_path =
"/sap/admin/public/index.html"
given host then
send request called check:
method: "GET"
path: {potential_path}
if "Administration" in {check.response.body} and {check.response.status_code} is "200" then
report issue:
severity: medium
confidence: certain
detail: `Sap information leaking found at the following path {potential_path}.`
remediation: "Follow the actions which are required in SAP Note 2258786"
end if
You start with a metadata block. It provides information about the script, the name, and the description of the script. Which will be visible in the burp issue activity dashboard. You can include the author's information for credit and finally, you can provide some tags. In our example, I used SAP, because it is only used for SAP applications and I used authentication bypass because that is the vulnerability. However, only the language and name property are required. It is best practice to provide all information.
The second part of the script specifies the run for each: statement
run for each:
potential_path =
"/sap/admin/public/index.html"
given host then
send request called check:
method: "GET"
path: {potential_path}
Here we define our potential_path variable. In this variable, you define the paths you want to perform the check on. In our case we want to perform one request just for the /sap/admin/public/index.html path. But it could be used to brute force your targets against a Seclist. It is important to know that because I used the given host then statement. This Bcheck will only run ones against the target system. This is best practice for this type of request because we only need to test this path once against a target.
In the given host then statement I specify that the request must be sent and that the results should be saved in a variable called check. The method is specified as GET and as path we use the predefined variable potential_path.
We end with verification. We know that if the variable check contains a response with status_code 200 and if the response contains Administration The vulnerability will have worked. There we report an issue.
You can set the severity, the amount of confidence that it isn’t a false positive, you can describe the report in detail, and give a remediation option.
if "Administration" in {check.response.body} and {check.response.status_code} is "200" then
report issue:
severity: medium
confidence: certain
detail: `Sap information leaking found at the following path {potential_path}.`
remediation: "Follow the actions which are required in SAP Note 2258786"
end if
Other options explained
There are more options then the given host then statement. Here are multiple other options explained which are from the official portswigger bcheck reference:
Every check script must contain a given / then
statement containing one of the following:
given response then
– The check runs once for each response audited.given request then
– The check runs once for each request audited.given host then
– The check runs once for each host audited. This is very useful for fuzzing dictionaries for example. Be wary that it will not rerun in the same project. So for retesting a new project should be opened.given any insertion point then
– The check runs once for each insertion point audited. Burp Scanner also uses this default option if you do not specify an insertion point type (i.e. you usegiven insertion point
).given query insertion point then
– The check runs once for each query audited.given header insertion point then
– The check runs once for each header audited.given body insertion point then
– The check runs once for each set of body content audited.given cookie insertion point then
– The check runs once for each cookie audited.
You can also use the or
keyword to combine insertion points. For example:
given query or body insertion point
then - The check runs once for each query or set of body content audited.given header or cookie insertion point then
- The check runs once for each header or cookie audited.
The format will always be:
given [response|request|host] | [ [any|query|header|body|cookie]* + insertion point] then
In our case, we will be using given host then
. Let me show you all the code, and then I’ll walk you through it.
Setup Burp Scanner to test .bcheck scripts
Running the BCheck scripts is easy.
Just run a new scan and select “Audit Checks — BChecks Only” in the scan configuration. Which can be selected from the Use a custom configuration and then Select from library.

Run an audit scan to trigger your .bcheck script
After running the audit scan against your target. If it is vulnerable the message will show in your burp issue activity board.

When pressed you get the created advisory based on the data provided in the script. It also tells which Bcheck is used!

The request and Response are also showing the checked values as normal.


Importing other Bchecks
There is a community already working on providing custom Bchecks. These can be downloaded and imported. Personally, I really find the tokens from puzzlePeaches very good! I as well included the SAP authentication bypass in this write-up.
It can be found on the following git page:
Be sure to make use of it.
These bcheck scripts are easily imported by pressing Import and selecting the required files with the extension .bcheck

If you want to export your already created bchecks in burp. They can be found at %appdata%\BurpSuite\bchecks
What is still missing
There are two actions I would love to see but are still missing.
- Making it possible to perform multiple requests based on the results of the first request.
For example, the first request in the bcheck analyses if the web application is a WordPress or a Joomla specific application. In the case it is a Wordpress application all Wordpress related Bchecks will run and in the case of a Joomla specific application all Joomla specific Bchecks will run. This linking of Bchecks is still not possible or to make two separate requests in the same bcheck. However, I believe it is in the road map.
2. Firing only specific Bchecks based on specific tags. In our case when I am testing a SAP application I do not require the standard wordpress Bchecks for example. Then I only want to run some specific Bchecks to limit the amount of request send to the target.
Conclusion
Burp Suite’s BCheck Scripts offer a powerful way to automate and enhance security testing. By leveraging these scripts, you can customize and extend your security assessments, making them both efficient and effective. With BCheck Scripts, you have the flexibility to tailor your tests and focus on specific security concerns, ultimately improving your security posture.
Remember to save your BCheck scripts to the library for future use, and start writing your own to uncover potential security issues in your web application landscape. And if you have some to share please perform a pull request to increase the amount of good quality checks!
Happy testing!
If you want to discuss anything related to infosec I’m on LinkedIn: https://www.linkedin.com/in/bobvanderstaak/
Or visit https://gripopsecurity.nl