Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Crawl.statusMessage in Montoya API is "Not yet implemented"

Jorian | Last updated: Mar 20, 2024 11:02AM UTC

In a project I'm working on, I am trying to automate the scanning of a target in Burp Suite Professional. Because existing solutions like https://github.com/NetsOSS/headless-burp are old and have deprecation issues, I am making my own extension for this with the new Montoya API. While doing so, I encountered a problem. The documentation says that the Crawl interface has a statusMessage() function to get the current status of the Task, but it also says this is "Not yet implemented", even when it is called from extension code. https://portswigger.github.io/burp-extensions-montoya-api/javadoc/burp/api/montoya/scanner/Crawl.html#statusMessage() If I'm correct, the steps to audit a single base URL are: 1. Crawl the URL 2. Create an Audit task 3. Push all in-scope sitemap URLs into the Audit task 4. Wait for completion of both tasks At some point I need to know when this process is done, so when all URLs have been crawled and audited. The Audit has a nice message that says "finished" when done, but I cannot figure out how to do this with Crawl. Is there any workaround for this or is this problem simply impossible with the Montoya API?

Hannah, PortSwigger Agent | Last updated: Mar 21, 2024 09:41AM UTC

Hi Have you checked out Burp's native REST API instead? You can use this to start a scan. You can also provide scan configurations with this, whereas with the Montoya API you can only use the default configurations. You can find our documentation on Burp Suite Professional's REST API here: https://portswigger.net/burp/documentation/desktop/settings/suite/rest-api Depending on how you wish to use Burp, Burp Suite Enterprise Edition may be better suited for configuring automated scans. This would be more useful if you're planning to scan at scale.

Jorian | Last updated: Mar 22, 2024 07:56AM UTC

Thanks for the reply. I have since gotten my extension to work using a workaround: monitoring the sitemap length. While it's not the cleanest solution, it does solve my problem. I have also checked out the REST API, which seems to be more fitting indeed. From the documentation I expected the REST API to only be accessible to Burp Suite Enterprise, but it turns out this feature is also available on Professional! This seems like a way better solution than trying to half-reimplement it myself, so I'll try using this now. Thanks for your help.

Hannah, PortSwigger Agent | Last updated: Mar 22, 2024 09:30AM UTC

Hope it helps! Please let us know if you need any further assistance.

Jorian | Last updated: Mar 22, 2024 03:11PM UTC

In the meantime, I have looked at the API and made it work in my use case, but there is one more small thing. For getting results, the `scan_callback` parameter should be used targeted to my server to receive the issues. However, it seems like this request has no authentication: ``` PUT /callback HTTP/1.1 Host: localhost:5000 Content-Type: application/json; charset=utf-8 Content-Length: 430 Accept-Encoding: gzip {"type":"ScanProgress","scan_metrics":{"current_url":"","crawl_requests_made":0,"crawl_network_errors":0,"crawl_unique_locations_visited":0,"crawl_requests_queued":0,"audit_queue_items_completed":0,"audit_queue_items_waiting":0,"audit_requests_made":0,"audit_network_errors":0,"issue_events":0,"crawl_and_audit_progress":0,"total_elapsed_time":0},"issue_events":[],"task_id":"3","scan_status":"paused","message":"","error_code":0} ``` How do I prevent an SSRF from messing with the results by sending me a bogus callback? It may be a bit of a far-fetched attack idea, but it would improve security. Would it be possible to add a secret to the scan request like a special header, that is sent in the callback to know it really came from Burp Suite?

Hannah, PortSwigger Agent | Last updated: Mar 25, 2024 04:04PM UTC

Hi Unfortunately, there is no way to add additional information to callback requests. You could consider adding some further validation on your endpoint, for example, checking the source IP of a request or validating the data that has been sent to your endpoint. Please let us know if you need any further assistance.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.