Feature #75987
closed
Implement request throttling/ rate limiting functionality and API
0%
Description
Our current brute force protection is non existent:
There are cases where specific functionality should be throttled, example: A user shouldn't hammer with 20 comments / second.
Task: Evaluate existing solutions (e.g. https://github.com/websoftwares/Throttle) and / or implement
a general throttling mechanism and provide API for extensions
Updated by Christian Kuhn almost 8 years ago
- Tracker changed from Bug to Feature
- Project changed from 1716 to TYPO3 Core
- Description updated (diff)
Updated by Helmut Hummel almost 8 years ago
Some usecases:
- Throttle failed backend logins
- Throttle the amount of contact forms sent
- Throttle the amount of comments sent
So basically
Throttle <condition> <action>
We need an API for conditions and resulting actions when condition is matched
Updated by Simon Schaufelberger over 5 years ago
My TYPO3 website was just attacked by a bot with 1000s of requests which killed my db with an exception like: Connection failed with: "An exception occured in driver: Too many connections" | TYPO3\CMS\Core\Error\Http\ServiceUnavailableException thrown in file /vendor/typo3/cms/typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php in line 932
I'm also using laravel for some projects and they have it implemented in the core with a middleware: https://github.com/illuminate/routing/blob/master/Middleware/ThrottleRequests.php
Updated by Sybille Peters over 2 years ago
@Helmut Please check if you see this as related. Otherwise I can remove the comment.
I assume you are looking at incoming requests. I would also like to add outgoing requests - the mechanisms (API) used might be similar.
e.g. throttle outgoing HTTP requests in linkvalidator (and elsewhere?).
I think there may be other cases as well where outgoing requests are made.
I already added an issue Make linkvalidator crawling polite specifically for this, but if you are adressing this topic in general, that would be cool to consider that as well.
I see that as problematic if TYPO3 does not throttle outgoing HTTP requests, see also my comment https://forge.typo3.org/issues/89287#note-4
Updated by Sybille Peters over 2 years ago
About the DOS attacks or too many requests - should that not be better handled elsewhere, preferably before the attacker reaches TYPO3 / PHP or even the webserver?
Updated by Helmut Hummel over 2 years ago
- Related to Feature #93825: Introduce rate limiter component added
Updated by Helmut Hummel over 2 years ago
- Related to deleted (Feature #93825: Introduce rate limiter component)
Updated by Helmut Hummel over 2 years ago
- Has duplicate Feature #93825: Introduce rate limiter component added
Updated by Helmut Hummel over 2 years ago
- Status changed from New to Closed
Sybille Peters wrote in #note-6:
About the DOS attacks or too many requests - should that not be better handled elsewhere, preferably before the attacker reaches TYPO3 / PHP or even the webserver?
I agree that it does not make much sense to implement a DOS protection in PHP, that should prevent overloading PHP resources.
Such protections (if necessary) should indeed be applied in a different layer of the network stack.
There are however scenarios, where rate limiting should be applied on functionality that is related to the application domain.
Examples for these are:
- authentication requests for a specific user account (currently implemented)
- contact form submissions
- etc.
These use cases (and all I had in mind) were related to incoming requests.
Sybille Peters wrote in #note-5:
I assume you are looking at incoming requests. I would also like to add outgoing requests - the mechanisms (API) used might be similar.
e.g. throttle outgoing HTTP requests in linkvalidator (and elsewhere?).
But the currently introduced Symfony rate limiting API is very generic. Without looking at the concrete implementation of this API,
I would assume it could be used to limit this interaction as well. Not sure though. I'd create a new ticket for each concrete use case anyway and within that ticket, we can evaluate options about possible implementations.
In any case, this ticket here is resolved from my pov with the given implementation. I will therefore close it.