Another DOS…
-
…at least locally.
click on search, type in term, press enter. The first found topic will be loaded. Now re-activate search, then press and hold enter. Similarly to the "password reset" issue, massive numbers of requests will be made. I managed to get 2 cores up to 100% utilisation, and lock Chrome entirely.
Christ alone knowns what it did to Alex's server, but I imagine it wasn't overly pretty. Responses didn't seem to be coming back fast enough to have been cached server-side. The responses have X-Runtime headers that differ each time, and all seem to be in the 0.5 sec range.
[edit] if you search for "likes", the first (and therefore default) result is everyone's favourite thread. enter-spamming this one will instalock your browser for minutes at a time.
-
I continue to be amazed that things that should be rate-limited (i.e. flood control) are not and that things which should not, are.
-
How would they rate limit requests to the server?
-
How would they rate limit requests to the server?
Disable the form until a response gets back from the server, and/or put a short sleep (like 50 - 100ms) in the server-side code
Won't stop scripts, but it will prevent regular users abusing the feature using built-in UI.
-
By dumping messages that come faster than x.
Basically your webserver is configured to parse headers, and if you're on linux you use IP tables/whatever as part of your setup.
At a minimum, you should cache recent searches and provide static results if it's been less than say, 30 seconds.
-
Drop the request, don't bother processing it, or delay sending the response to try and tar pit them.
-
or delay sending the response
Oh, the response is definitely "delayed", but somehow I don't think it's deliberate
-
How would they rate limit requests to the server?
There's two parts to this. On the one hand, they could do all kinds of munging events to limit the requests being sent in the first place. This behaviour should not even be possible for regular users to pull simply by holding down enter.
On the other hand, you have a flood control routine prior to the actual effort and lock out people who are trying to hammer the server - like all those crappy PHP ones do.
-
Won't stop scripts, but it will prevent regular users abusing the feature using built-in UI.
Or a weight to hold down the Enter key?
-
Disable the form until a response gets back from the server, and/or put a short sleep (like 50 - 100ms) in the server-side code
And have the time to sleep be a product of exponentiation so that it gets exponentially more delayed.
-
We really should test these over at meta.d, just to make sure they have not been taken care of by a software update that they have not pushed to the downstream yet... ;)
-