search

blst-security / cherrybomb

Stop half-done APIs! Cherrybomb is a CLI tool that helps you avoid undefined user behaviour by auditing your API specifications, validating them and running API security tests.
https://www.blstsecurity.com/cherrybomb
Apache License 2.0
1.16k stars 83 forks source link

Clearer mechianism to disable active scans #78

Open jayvdb opened 2 years ago

jayvdb commented 2 years ago

Is your feature request related to a problem? Please describe. I have a demo server provided by a vendor, and dont want to be performing active scans on it. The passive scans are still quite useful.

Describe the solution you'd like A clear way to disable the active scans.

Describe alternatives you've considered I tried cherrybomb oas --active-scan-checks "" --file .. but that replied with

error: The following required arguments were not provided:
    --exclude-active-checks <EXCLUDE_ACTIVE_CHECKS>

I was able to get it to disable the active scans using

cherrybomb oas --active-scan-type 3 --active-scan-checks "" --exclude-active-checks 0 --file ..

The isn't very intuitive. If a simpler approach isnt possible, perhaps that sequence could be mentioned in the README or some docs, so that the tool doesnt default to active scanning unless the user is aware that will happen.

Additional context Add any other context or screenshots about the feature request here.

OmerWow commented 1 year ago

Hey @jayvdb

Thanks for the feature suggestion!

We are looking into it, and the next version should include a more user-friendly CLI.

Also, we're planning on releasing v1.0 soon, and we're considering adding a config file to Cherrybomb that will allow you to change settings easily and even save them for future runs. Do you have anything else you would like to see added as an option in this config file?

jayvdb commented 1 year ago

Being able to disable specific checks only on a specific schema or endpoint would be handy in order to whitelist existing parts of the OAS while preventing reoccurrences of the problem on new parts of the OAS.

When designing the new config file, it may be helpful to allow supporting the https://github.com/stoplightio/spectral (TS) config, which is also supported by https://github.com/daveshanley/vacuum (Go), which allows defining custom rules, e.g. https://github.com/co-cddo/api-standards-linting/blob/main/spectral-ruleset-govuk-public/ruleset.yaml

OmerWow commented 1 year ago

Being able to disable specific checks only on a specific schema or endpoint would be handy in order to whitelist existing parts of the OAS while preventing reoccurrences of the problem on new parts of the OAS.

When designing the new config file, it may be helpful to allow supporting the https://github.com/stoplightio/spectral (TS) config, which is also supported by https://github.com/daveshanley/vacuum (Go), which allows defining custom rules, e.g. https://github.com/co-cddo/api-standards-linting/blob/main/spectral-ruleset-govuk-public/ruleset.yaml

Hey @jayvdb

When it will be released, there will the option to disable/enable specific checks using said configuration file :)

Regarding adding support for the format you've mentioned, it's not something we have planned right now but we will consider it, thanks!