How can we protect against sitekey abuse?

[thraizz]

Hi,
We decided to choose FriendlyCaptcha for a current project and are so far very happy, integrates really well!

We also discovered that the request limit counts towards client-side puzzle requests. Initially we thought this limit would apply against server-side validation. It would be cool to explain this limit or just call it "limit of puzzle requests" in the docs, as it is called in the account usage stats 😺

I thought it would be server-wise, so that we can block malicious/suspicious clients after a failed validation and don't use up all our requests client-side.
Now that this is not possible, we are trying to limit the possibility of bots using up all our requests / month in some other way.
What prevents crawlers or bots from requesting a puzzle? Is there any protection against this, which I don't see at the moment? We are using the javascript API and solve the puzzle on page load, so that we can protect our site with an invisible captcha.
Thanks for the cool tool!

[BenjaminVettori]

I have the same question.
Initially I also thought, it would count the validation requests.
However, when I looked at the statistics page, I saw that unsolved puzzles increase the "used" count.

What happens if the request limit is used up, will it still return puzzles?
If yes, what does the verification api response contain in such cases, will it just return success?

If it just succeeds, from my understanding, an attacker could simply request puzzles for your site-key until the limit is used up and from then on all validations pass automatically?

That would effectively make it obsolete to solve puzzles and reduce the spam protection to "downloading X puzzles" (depending on your price plan) instead of solving them. At least it is questionable if the limited request count price plans make any sense in this case.

[gzuidhof]

This is a valid question for sure, I'll try to provide some context in a list, do let me know if something is missing or unclear:

• We don't shut down accounts that are over their puzzle request limit (without first getting into contact). The API will keep working and validating puzzles. For accounts on any level paid plan this is a manual process, for free account plans we intend to be a bit stricter in an automated fashion.
• An overage is fine every now and then, and we don't want to just turn off protection (that doesn't help anyone!).
• Puzzles requested with your sitekey have no use for an attacker if they don't intend to solve and use them, they can only be validated with your API keys. (In other words: I can't use your sitekey on my website and have you pay my bill).
• In the near future (this quarter) we want to allow you to specify a limited set of origins from which puzzles can be requested.
• For puzzle requests we store the headers made to use the request as well as an anonymized value derived from the IP address (so we can see if a large amount of puzzles are requested from a single source).
• If your account sees many requests that are never submitted then that is suspicious. Repeating a bit: we manually look into these overages (a plot of requested puzzles vs succesfully verified puzzles tells a big part of the story), so we make the judgement call whether we will ask you to upgrade to a bigger plan or whether this was someone malicious requesting many many puzzles. Of course we're happy to back up our request to upgrade with some screenshots of your data (eventually you'd be able to explore this data yourself).
• We are currently working on a new version of the dashboard in which we want to also incorporate visualizations of this data (right now you can only see the numbers in the dashboard which is harder to interpret). It's hard for me to promise a date for this though - us manually going through it does the job for now.

I hope that clarifies the current situation and a bit about where we are headed. We really do try to be transparent, reasonable and fair. Let me know if you have any follow-up questions (or just make another issue later) - I'll close this issue in a week or so of no new comments :)

[BenjaminVettori]

Alright, thas sounds promising to me @gzuidhof !

I guess it could also be stated in the documentation or maybe some Q&A section on the homepage, what you do if the limit is reached. At least I did not find an answer for this case somewhere else.

Regarding the origin restriction: I am not completely sure if an origin limitation can solve the (puzzle) request count exhaust, but I also don't know how you plan to implement it.

If it is based on the origin header:
From my understanding, the Origin header is in control of the client (browser, rest client, command line tool, ...).
That means, an attacker can use a script / tool to perform the request and therefore he could also set an arbitrary origin to request a puzzle, right?
But I am looking forward to see how you plan to do this origin checks and I guess I will try to circumvent them to test if they work as expected, once it is possible to configure them for a site key.

For me it was important to know, that an attacker is not able to circumvent the puzzle solving.
Even if he downloads 1 million puzzles, he has to solve at least one of them to perform a valid request to the backend.
This means an attacker can produce high request count statistics in the dashboard of an account, but the captcha still works as expected.

[davidbeermann]

At my company we've implemented the following solution: we proxy the puzzle API request through an internal API. The WidgetInstance is configured to call our endpoint and we add a random string to the WidgetInstance options for the key sitekey. The sitekey just needs to have a value that is not an empty string for this to work.

However, the protection of our sitekey was just a welcome side effect for a different problem we wanted to address. Initially we saw SSL cerificate errors since our companies certificate has a broader support with older operating systems than Friendly Captcha's Let's Encrypt certificate. By proxying the request through an API endpoint on the same domain as our app we were abe to solve this.

Two birds, one stone. 😄

[SteffenDE]

So the documentation for automated testing recommends to just mock the verification request, but all automated puzzle requests would count towards the limit. Don't you think that this is problematic?
Our automated test pipeline runs hundreds of times a month with three browsers each and multiple tests that would all request a puzzle with this setup.
While reading the documentation I also thought that only the verification requests would be counted, so this should definitely be clarified.

[gzuidhof]

Hi Steffen,

We're happy to think along of course in special situations.

Usually the amount of automated requests for integration testing, even if they are hundreds per month, pale in comparison to the amount of legitimate requests (thousands vs hundreds of thousands or millions) - if that is different in your situation then let's find a solution.

One clientside solution would be to not request a puzzle in case of your automated test, so you would put a clientside if somewhere, and not inject the widget in case it's your automated tester: if (navigator.userAgent.includes("my-automated-tester-user-agent").

A different solution that doesn't involve code would be to reach out to our support and we can talk about your exact situation more.

[SteffenDE]

Thank you for the quick reply. We already worked around this by not including the captcha while testing, so that's not a real issue for us.
I just think that the documentation should probably mention this. Something like:

"Note that puzzle requests will still count towards the request quota. To prevent this you can exclude the widget from the page while testing."

[pgtaboada]

Having an overusage does not solve the problem with the abuse. If someone has targeted one website with the intend to produce costs, this is an easy approach.

I wouldn't raise the issue if it did not happen to us (not with friedlycaptcha) before.