Remove detector for chatbot.com

[aPoCoMiLogin]

Description:

Recently i've been reworking WAF rules and noticed that there were few rules that had outstanding numer of blocked requests (see attached screenshot). i'd like to remove this detector on behalf of the organization (Text, Inc.) i'm working for, especially as this detector will not work as it's blocked by WAF rules. hope that sounds reasonable.

Checklist:

• Tests passing (make test-community)?
• Lint passing (make lint this requires golangci-lint)?

[CLAassistant]

All committers have signed the CLA.

[camgunz]

Hey @aPoCoMiLogin -- sorry you're getting a lot of verification requests to that endpoint. Is there a different, more efficient verification endpoint we can use? It's really useful for users to check if they have any leaked secrets for their services, and many services have a very simple, low-database load endpoint for verification. We could implement some rate limiting for your API; do you return 429s or have rate limiting headers we can honor?

[aPoCoMiLogin]

Hello there. I'm afraid that even if there was such endpoint, the WAF rules would block either user-agent or IP address after some amount of unauthorized requests. It would require us to create specific endpoint that is excluded from some of the WAF rules, which I'm not sure that my organization would agree to.

so at that point, this detector doesn't work since it was created (the user-agent is already blocked) if someone is running self-hosted with different user-agent, it's IP will be blocked after some time anyway (there is quite a few IPs already blocked..); kind of no-win situation currently

[camgunz]

Looking at the token format, there's nothing to distinguish it from some random-ish data, and formats like that can lead to a lot of spurious verification requests. Something that would help us--and other secret scanners--is if the token had some kind of identifier like chatbotcom_<token>. We're looking at putting detection for these kinds of tokens behind a flag that's default off, but like you pointed out this isn't ideal.

Overall though, we're unlikely to outright remove a detector. Users might not be scanning lots of data, they can always run w/ verification disabled, we've got mitigations in place to avoid too many duplicate verification requests on the enterprise side, and there's still some things we can do to reduce requests and respect rate limits. All that said, we'd love to work together; the 2 things off the top of my head are: we can do some work to respect your rate limit policy if you give us some info on how to do that, and we can help cook up a more identifiable token format. I hope we can figure out a way forward here; it's really valuable for users to be able to find leaked secrets and generally we all have to work together to make that work smoothly.