The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Schedule a scan with the Burp Enterprise graphql API

Fabian | Last updated: Jan 14, 2021 04:43PM UTC

I'm trying to schedule a scan with the Burp Enterprise graphql API, but it alwas returns an unexpected error. An example query would be: mutation Schedule { create_schedule_item(input: { site_id: "1", schedule: { initial_run_time: "2021-01-14T11:02:45.575Z" } }) { schedule_item { id } } } After investigating the logs, it seems like the validation of the timestamp fails. I've tried several different date formats but did not have any luck. Does anybody know a valid format for a timestamp or can tell me if I am doing something substantially wrong?

Uthman, PortSwigger Agent | Last updated: Jan 15, 2021 09:14AM UTC

Hi Fabian, If you create the scan in the portal and look at the dev tools > Network tab, you will see a v1 request with the appropriate format. Can you try this out? For example, 2021-01-16T09:15:00+00:00

Fabian | Last updated: Jan 15, 2021 09:32AM UTC

Unfortunately I did not have any success. I copied the timestamp and got this query: mutation Schedule { create_schedule_item(input: { site_id: "1", schedule: { initial_run_time: "2021-01-15T10:35:00+01:00" } } ) { schedule_item { id } } } Still the same error. The log says: 2021-01-15 10:28:56 [qtp1896562278-3853] WARN n.p.enterprise.web.graphql.a.d - Error handling request graphql.schema.CoercingParseValueException: Expecting a Timestamp String at net.portswigger.enterprise.web.graphql.a.c.b(Unknown Source) at net.portswigger.enterprise.web.graphql.a.c.c(Unknown Source) at net.portswigger.enterprise.web.graphql.a.c.parseLiteral(Unknown Source) at graphql.validation.ValidationUtil.parseLiteral(ValidationUtil.java:113) The stack trace is quite a bit longer. Let me know if the full stack trace would help you.

Uthman, PortSwigger Agent | Last updated: Jan 15, 2021 09:46AM UTC

Thanks, Fabian. I have replicated the issue. What API client are you using? Insomnia? Postman?

Fabian | Last updated: Jan 15, 2021 10:17AM UTC

I'm using Insomnia. So this is a problem with Insomnia and not Burp?

Uthman, PortSwigger Agent | Last updated: Jan 15, 2021 11:42AM UTC

We are still looking into the cause and will update this thread with any findings. Can you confirm the version of Burp Enterprise you are running? Did the same query work in a previous version?

Fabian | Last updated: Jan 15, 2021 11:54AM UTC

I just installed Burp Enterprise the day before yesterday, so I only tested with that version. Therefore I cannot give any information about previous versions. Here are my diagnostics from the web interface: Your setup Version: 2020.12 Build: 5930 Scanner version: 2020.12.1 Database: h2 Database version: 1.4.197 Max memory: 4 GB Total memory: 4 GB Available processors: 16 Java version: 9.0.4 OS name: Linux OS version: 5.10.4-arch2-1 OS arch: amd64 Installation: /opt/burpsuite_enterprise/enterpriseServer/2020.12 Logs: /var/log/BurpSuiteEnterpriseEdition Log disk space: 307 GB Disclaimer: I have 16GB of memory on this machine, not just 4GB. I'm also not sure why only 4GB are displayed.

Uthman, PortSwigger Agent | Last updated: Jan 15, 2021 12:30PM UTC

Thanks for that information. Our developers have identified a bug but you can use the workaround of using variables. For example: {"operationName":"CreateScheduleItem","variables":{"input":{"site_id":"3","schedule":{"initial_run_time":"2021-01-17T12:05:00+00:00","rrule":"FREQ=DAILY;INTERVAL=7"},"scan_configuration_ids":[]}},"query":"mutation CreateScheduleItem($input: CreateScheduleItemInput!) {create_schedule_item(input: $input) {schedule_item {id}}}"} In the main request window, you would need to add: mutation CreateScheduleItem($input: CreateScheduleItemInput!) { create_schedule_item(input: $input) { schedule_item { id } } } You can then add the below in the 'Query variables' section: { "input": {"site_id":"3","schedule":{"initial_run_time":"2021-01-17T12:05:00+00:00","rrule":"FREQ=DAILY;INTERVAL=7"}} } We will update this thread when the bug has been fixed.

Fabian | Last updated: Jan 15, 2021 12:45PM UTC

Oh wow, that works. Thank you very much! I actually have a question regarding another graphql query. Should I open another thread for that?

Uthman, PortSwigger Agent | Last updated: Jan 15, 2021 01:09PM UTC