Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

REST API. Get scan status after Burp restart: Task ID not found

Oleksii | Last updated: Nov 20, 2019 03:03PM UTC

Burp Suite Pro version: 2.1.05; Steps to reproduce: 1. Start Burp Suite Pro; 2. Launch new scan, using REST API, i.e. do HTTP POST scan configuration to http://127.0.0.1:1337/$apiKey/v0.1/scan; 3. Poll scan status with HTTP GET http://127.0.0.1:1337/$apiKey/v0.1/scan/$taskID; 4. Stop Burp Suite; 5. Launch Burp Suite again with --unpause-spider-and-scanner command line option; 6. Scan status poll fails with HTTP 400: {"type":"ClientError","error":"Task ID not found"} Expected behavior: Burp Suite stores taskID in project file/temporary directory and allows to poll scan status even after Burp Suite restart.

Liam, PortSwigger Agent | Last updated: Nov 20, 2019 03:51PM UTC

You should be able to find the Task ID in the "location" header. Please let us know if you need any further assistance.

Liam, PortSwigger Agent | Last updated: Nov 20, 2019 03:55PM UTC

To view the task_id of an item, you can: 1) Note the value of the location header that is returned when you start the scan. 2) Look at the Burp Dashboard tab. 3) Configure a callback URL and note the task_id in the body of the request.

Burp User | Last updated: Nov 20, 2019 04:26PM UTC

I know where to find task ID, but the report isn't about it. Say, you received a response to POST request and saved task ID from 'Location' HTTP header, then you can perform HTTP GET requests with this task ID to obtain scan status and all works just fine until... After Burp Suite restart you will not able to poll scan status because Burp Suite responds with HTTP 400: {"type":"ClientError","error":"Task ID not found"} whatever you give it as a task ID. Read my steps to reproduce carefully, please.

Burp User | Last updated: Nov 21, 2019 01:32AM UTC

Dear Support, This issue has a significant impact on the way we are trying to utilize Burp Pro 2.x via API. In our case, the some targets we test are not available 24x7, so we have to deal with suspending the scan & audit and resuming it later. However, doing that via API does not work as the TaskID is not recognized by Burp Pro after the restart. Please advise. Thanks, Alex.

Liam, PortSwigger Agent | Last updated: Nov 21, 2019 02:55PM UTC

Sasha, we reproduced the behavior you are having an issue with. We'll discuss this with the appropriate product team and get back to you.

Burp User | Last updated: Nov 25, 2019 07:59PM UTC

It's great news, Liam, thank you! Please keep me posted or let me know otherwise what we can do to get the fix for this behavior prioritized /expedited. Sasha.

Michelle, PortSwigger Agent | Last updated: Nov 26, 2019 01:15PM UTC

Hi We've raised this as a bug with our product team, we don't have an ETA for the fix as yet.

Synack | Last updated: Feb 17, 2020 10:07PM UTC

Hi, do you have and updates on this issue? Thanks, Sasha.

Michelle, PortSwigger Agent | Last updated: Feb 18, 2020 10:33AM UTC

Hi Sasha This issue is in our backlog, we don't have an ETA as yet, but we've linked this thread so we can post an update when there's news.

Prateek | Last updated: Sep 11, 2020 04:41PM UTC

Hi Team, while trying to use Burp rest API to perform scans, we are gtting back 400 Bad Request for few domain urls. Please advise { "type": "ClientError", "code": 1101, "error": "Unknown host: example.domain.com" }

Michelle, PortSwigger Agent | Last updated: Sep 14, 2020 07:51AM UTC

An 'Unknown Host' error means that the hostname entered in the REST API command cannot be resolved so the scan cannot be started. Can you connect to the site from the machine running Burp?

Prateek | Last updated: Sep 14, 2020 08:32PM UTC

Hi Team, We are able to access the urls using BURP proxy(which means browsing the application with Burp proxy in the browser) and able to scan these urls by selecting the urls from Http History tab. But, we are not able to submit a scan request using REST API, which is returning as Bad Request "Unknown Host" Could you please advise on the workaround to resolve this issue. As every host need may not be resolvable using ping and these may be hosted in internet and cloud (eg: Azure, ecp). ping will fail for many other sites too..

Michelle, PortSwigger Agent | Last updated: Sep 15, 2020 07:47AM UTC

Can you send us a copy of the command you are sending via the REST API so we can take a closer look, please? You can share this directly via email if you prefer using the address support@portswigger.net

Prateek | Last updated: Sep 16, 2020 03:58PM UTC

As an example using an internet site Bank Of America curl -vgw "\n" -X POST 'http://localhost:1337/v0.1/scan' -d '{"urls":["http://bankofamerica.com"]}' { "type": "ClientError", "code": 1101, "error": "Unknown host: bankofamerica.com" }

Prateek | Last updated: Sep 16, 2020 03:59PM UTC

We are seeing the same error for other internet applications as well

Uthman, PortSwigger Agent | Last updated: Sep 17, 2020 09:35AM UTC

Thanks for the feedback. Our development team is working on a fix and we will update this thread when that has been implemented.

Prateek | Last updated: Sep 18, 2020 04:45AM UTC

Thanks, meanwhile is there a workaround to skip this check for ping to proceed with scan request

Uthman, PortSwigger Agent | Last updated: Sep 18, 2020 07:49AM UTC

Sorry, Prateek. It looks like your issue is different from the issues in the main thread. There is no ping. Burp will perform a DNS lookup of the host from the machine you are scanning from (or the machine the REST API is running from, in this case). Do you have any issues launching a scan on the HTTPS version? Do you have an upstream proxy set up? Can you send us further details via email, please?

burpons | Last updated: Dec 09, 2021 04:44PM UTC

Hi @Uthman, Does this bug has been fixed ? Best regards.

Uthman, PortSwigger Agent | Last updated: Dec 09, 2021 07:55PM UTC

@burpons this is currently in our development backlog so no update yet, unfortunately. We'll update this thread when we have further information.

Zsolt | Last updated: Jun 10, 2024 12:39PM UTC

Hi, It is 2024 and the issue is still present. I am running Burp 2024.4.5. Steps: 1. Started scan with REST API 2. Stopped Burp 3. Restarted Burp, with --unpause, I can confirm that Task 3 is running without an issue in the restarted Burp using the UI 4. curl -v http://localhost:1337/[SECRET]/v0.1/scan/3 and get this response: * Host localhost:1337 was resolved. * IPv6: (none) * IPv4: 172.20.0.2 * Trying 172.20.0.2:1337... * Connected to localhost (127.0.0.1) port 1337 > GET /[SECRET]/v0.1/scan/3 HTTP/1.1 > Host: localhost:1337 > User-Agent: curl/8.5.0 > Accept: */* > < HTTP/1.1 400 Bad Request < Content-Type: application/json; charset=utf-8 < X-Content-Type-Options: nosniff < X-Frame-Options: DENY < Content-Security-Policy: default-src 'self'; script-src 'self'; img-src 'self'; style-src 'self'; frame-src 'self'; connect-src 'self' ws://localhost:3333; font-src 'self'; media-src 'self'; object-src 'none'; child-src 'self' blob: < X-XSS-Protection: 1; mode=block < Cache-Control: no-cache, no-store, must-revalidate < Pragma: no-cache < Expires: 0 < X-Burp-Version: 2024.4.5-29256 < Keep-Alive: timeout=15 < Content-Length: 50 < * Connection #0 to host burppro left intact {"type":"ClientError","error":"Task ID not found"}

Michelle, PortSwigger Agent | Last updated: Jun 11, 2024 08:16AM UTC

Hi We do still have this request logged. I'm sorry but when being prioritised against other bugs and features it has not yet been moved forward. Burp Suite Professional is primarily a manual testing tool rather than something to be used for automation, so this does have an impact on how it has prioritised. Over the years since this thread started we have not had many users reporting this, we will add your voice to the list we currently have so that this can be monitored.

Zsolt | Last updated: Jun 11, 2024 08:53AM UTC

Dear @Michelle, Thank you for your quick response and for providing insight into the prioritization process for bug fixes and feature requests. I understand that Burp Suite Professional is primarily designed as a manual testing tool and that this impacts how requests are prioritized. However, I would like to emphasize that for users with programming knowledge, the REST API is an invaluable tool. The issue I reported significantly hampers the usability of the API, especially for long-running scans, which can be a critical aspect of many automated testing workflows. Addressing this bug would greatly enhance the efficiency and reliability of using Burp Suite Professional in such scenarios. I appreciate your attention to this matter and hope that this bug can be prioritized for resolution in future updates. Thank you again for your time and support. Best regards, Zsolt

Michelle, PortSwigger Agent | Last updated: Jun 11, 2024 02:27PM UTC

Thanks for the feedback, I will share this with the team. To help us get a better understanding of your workflow, would you be happy to share more details on scenarios where the REST API is important for you, how you use it and how often you make use of it? If you'd rather not share this level of detail on the forum, feel free to send it via email to support@portswigger.net

Zsolt | Last updated: Jun 19, 2024 11:21AM UTC

Hi, We are running weekly scan of our website and APIs (4 different scans at the moment). Triggering the scan is automated and checking status and completion of it is handled by the rest api. Unfortunately we cannot guarantee that Burp can run 100% of the time, so it is possible that the job running it will restart, this is when we need to recover. All settings, project file, etc is available, so if the rest api call would work on all tasks, it would be possible. BTW, the scan was started by the REST API, just in a previous instance of Burp, before the restart. Upon restart the task actually continues as expected, just the query does not work.

Hannah, PortSwigger Agent | Last updated: Jun 19, 2024 04:07PM UTC

Hi A limitation of the REST API is that it is only able to retrieve results from a scan it has initiated. After restarting Burp, the method of initiating the scan is no longer from the REST API, so it is not able to retrieve the results. If you're looking to run repeated scans of websites and APIs, the Burp Suite Enterprise Edition is a better fit for your use case than Burp Suite Professional. It is designed for automated, recurring scanning of sites, and tracking these results over time. It also has a large range of other features available for more automation and scanning at scale. If you'd like to find out more, you can check out our website here: https://portswigger.net/burp/enterprise

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