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
619 stars 109 forks source link

Given "directory" feature request #86

Closed ldionmarcil closed 1 year ago

ldionmarcil commented 1 year ago

Hi all, as a continuation of the discussion here (Issuing requests to each directory in a URL) https://github.com/PortSwigger/BChecks/issues/6, I'd love to know if there could be a way to run bchecks on all folders, for all hosts. Right now, as far as I know we can trigger a bcheck on every host and every query.

The use case that I am interested in is Tomcat path normalization. The current way that I see bchecks being leveraged for finding files in a folder, is to do a "given request" and do a regex replace to hit the directories under that path. However, this will trigger for every single request in specific directories, thus triggering continuously. For example, this bcheck here looks for potential php files at the root of the directory. If we manually request "/foo/bar" on a server, the bcheck will check for "/foo//php.php", "/foo//phpinfo.php", "/foo//php.php", "/foo//info.php", etc. as expected. However, if we manually request /foo/baz", the bcheck will once again check for "/foo//php.php", "/foo//phpinfo.php", "/foo//php.php", "/foo//info.php", etc., duplicating requests uselessly.

We can "minimize" this by checking the "ignore duplicate items based on URL and parameter names" setting in the scanner task, so it doesn't keep triggering over and over for the same initial request, but it'll still trigger for all other endpoints under that particular folder.

To illustrate the issue, lets take a simple web application loading a javascript file, a css file, and an image (4 requests). If all of these are in the same directory-path, it would be nice if the bcheck had a way to check for those potential paths only once per directory. Right now, the bcheck would trigger 4 times (once for the initial request plus 3 for each asset), thus generating 105 requests total, when 21 only were necessary. This quickly gets out of hand on modern apps with hundreds of assets, generating thousands of unnecessary requests for repeat checks.

I think a solution would be to be able to have an event handler that would trigger on each directory per host. If we could do something like this, for example

run for each:
    potential_path =
        "/foo"
        "/bar"
        "/baz"

given directory then
    send request:
        path: ${base.request.directory}${potential_path}

[...]

This would allow us so much more flexibility to run checks for directory-related issues (leftover debug files, path normalization, etc). Obviously this would need to be tracked the same way requests are tracked currently with the "ignore duplicate items based on URL and parameter names" setting.

Thank you for considering this!

Hannah-PortSwigger commented 1 year ago

Thanks for the feedback! We've added your +1 to this feature request.

We're currently gathering feedback on BChecks to help us decide where to take BChecks next, so any input is valuable to us :)

ldionmarcil commented 1 year ago

Thanks. Is there a public roadmap regarding the bcheck project? I see some tickets have received the "enhancement" label for feature request, while some are being closed (like this one). Just trying to have an idea of what gets accepted, and perhaps a rough timeline. Thanks again!

Hannah-PortSwigger commented 1 year ago

Unfortunately, we don't have a public roadmap for BChecks specifically. You can find our public roadmap here.

We should be doing another push on BChecks later this year, taking on board the feedback we've gained from the current functionality.

BuffaloWill commented 8 months ago

I apologize if I missed it @Hannah-PortSwigger , did this get released? It would be a great feature.

Hannah-PortSwigger commented 8 months ago

Hi @BuffaloWill

There's a new control flow item, given path then in the v2-beta language version. You can find this here. There is also some more information in the Wiki, here.

Does this cover your use case?