Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help Us Shape The Future of burp-rest-api #75

Open
ikkisoft opened this issue Nov 1, 2018 · 11 comments
Open

Help Us Shape The Future of burp-rest-api #75

ikkisoft opened this issue Nov 1, 2018 · 11 comments

Comments

@ikkisoft
Copy link
Collaborator

ikkisoft commented Nov 1, 2018

Since the first commit of this project (back in 2016), burp-rest-api has been the default tool for Burp-powered web scanning automation. Many security pros and organizations have relied on this extension to orchestrate the work of Burp Scanner.

With the release of Burp Suite Professional 2.x (beta), things will change. The newly released version of Burp includes a native Rest API. While the current functionalities are very limited, this is going to change.

In the initial release, the REST API supports launching vulnerability scans and obtaining the results. Over time, additional functions will be added to the REST API.

While it's great that Burp users will finally benefit from a native Rest API, this new feature makes us wonder if it even makes sense to work on the project in its current state. We look forward to hearing from you whether / how burp-rest-api can still provide value. Help us shape the future of this project.

Thank you for your support so far!

The burp-rest-api contributors team

@Yarkul7
Copy link

Yarkul7 commented Nov 7, 2018

In my company we start using Burp Suite to automate security scanning as part of the CI/CD build pipeline. The burp-rest-api is an essential component to achieve the required level of automation. I've looked at the new Rest API of Burp Suite Professional 2.0 and in its current state the API is too limited for our testing approach.
I am not convinced that the official Burp API will eventually provide the same functionality as burp-rest-api. The reason being that with the new Burp Enterprise there is no real incentive for Portswigger to facilitate automation for Burp Suite.
That said, I am very grateful for all the work that went into burp-rest-api and I am definitely interested in supporting this project.

@ajbr0wn
Copy link

ajbr0wn commented Nov 14, 2018

Just to add another voice, I am also interested in continued support of this project. The new Rest API is not only limited in functionality, but it also has a larger price tag (not sky high, but) - so if there's a tool with customizability and more functionality for free, I think that's incredibly valuable.

@v-ststee
Copy link

v-ststee commented Mar 9, 2019

Just completed back-2-back testing of this API (burp-rest-api) versus the Burp Suite 2.0 rest api for production CI/CD builds using the "documentation" posted here ( https://laconicwolf.com/2018/08/27/exploring-the-burp-suite-api/ ) which is the most complete I could find to date. There is no comparison for robustness, transparency and functionality to what you have provided here according to my test runs. Without this API (burp-rest-api); Burp Suite professional 2.0 (beta) does not appear to perform any better than OWASP ZAP for automated scanning. With this API in place (burp-rest-api from this github repo), IMHO burp suite professional is the top shelf DAST scanning tool at any price. Please continue to support and maintain this very valuable tool extension.

@sujendram
Copy link

I would like to add a few cents here. we have been recently evaluating various DAST tools and integrate the best one into our CI/CD pipeline. we found burp with good scanning capabilities but cannot afford to buy an enterprise edition at this stage. Doing a bit of research we found this rest API extension and I was impressed by the capabilities. Also compared it with the default API provided by Burp but I don't find it to be any closer to what this extension does. I would like to see further enhancements to this extension and would continue to use it. Thanks

@IgorSasovets
Copy link

I tried many ways to automate BurpSuite runs but only burp-rest-api helps me to solve the issue. It has a lot of features that make life easier. I am definitely interested in future enhancements of this project. It has many advantages over the native Burp REST API. The biggest one is that using burp-rest-api I can run an active scan against the previously recorded scope. I wait for the new features in the burp-rest-api. The most desirable for me is an option that would allow to set a custom configuration for the active scan. It can help to significantly reduce number of false positives and speed up scans.

@kjoshiixl
Copy link

kjoshiixl commented Jun 23, 2020

The use case in which we plan on using the burb suite is as follows:
We have functional Selenium based Smoke tests for which we use the Selenium Hub/Nodes, burb proxies the traffic from the browser on the Selenium Nodes. I liked the api' burp-rest-api provides and i think it could provide a good way to integrate Security audits with the functional tests.
However there are a few things on which i needed some feedback on the usage of the api's:

  1. I saved the project (Project-> Save Copy), project setting and user setting which i load when i start from the command line, to load the CA certs and the intercept settings. Generate the reports through the REST API exposed. However between the smoke tests runs is there a way to clear the audit issue identified during the previous audit runs, as currently i see the audit report persists the audit issues from the previous runs.
  2. Is there some database entries which could be cleaned up in the *.project files.

@ikkisoft
Copy link
Collaborator Author

  1. is there a way to clear the audit issue identified during the previous audit runs

Please refer to #82. Unfortunately the best option at the moment is to restart the process after each smoke test.

@jchristman-plex
Copy link

Multiple years without an addition to the native API seems to point to it being a very low priority on Portswigger's part. This appears to be the only option for automation on a reasonable level.

@h888t
Copy link

h888t commented Jun 29, 2021

Burp's default REST API in the Pro version can be described as 'minimal' at best - this project is highly valuable.

@ikkisoft
Copy link
Collaborator Author

Portswigger released an all-new API named Montoya API.
Please refer to https://portswigger.net/burp/releases/professional-community-2022-9-5 for more details.

While this does not currently affect the project, it makes me wonder on the future of burp-rest-api.

Rewriting the entire extension for Montoya API is a significant investment in time. Unless there's a company willing to sponsor the effort, I am not sure we (@doyensec) will have the time to do that.

Additionally, it would be interesting to perform a comprehensive comparison between burp-rest-api, the native Burp's REST API and the Burp's Enterprise version. If there is anyone interested in this, please reach out to me.

@BurningNetel
Copy link

Recently evaluated the enterprise version (and many other DAST products similar) to find a good solution for automation. The problem with these tools is that you can't proxy traffic trough it. HAR files, openapi specifications or similar recording methodologies have their own limitations or require different approaches to recording and configuring which is not always wanted. So right now, those products are just not on par with the ease of use and flexibility that Burpsuite Pro's proxy has combined with this API. Especially if you have some kind of end to end testsuites already in place.

I hope Burp will keep the legacy API around for long so we can keep using this project as long as possible. I am also not sure what rewriting to Montaya would mean or what it even is capable of in practice compared to the legacy API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants