3

How can I restrict users from spamming my web service by sending thousands of requests?

My web service is actually protected by a validation token only accessible through authentication, but I still can't avoid the fact that my web service will check if the token exists in my database.

I thought about saving the number of attempts by IP, but still, I would have to check every time in my database if the trying IP is blacklisted.

Is there any way to avoid web services spammers?

4 Answers 4

1

Fail2ban is a nice option, but it will create some problems if a sizable part of your userbase is behind a proxy, and someone on that proxy abuses your service and locks out every single user of the proxy.

You probably have a traditional database (MySQL, Postgres, Oracle, DB2) hosting your data, but the overhead of the tokens are too high for them.

You could use a small NoSQL database just for the tokens, and let the main database take care of the data. Redis is a good option, and CouchBase is another good one. Couchbase is known to be very fast, so I would try it first. On the other hand, Redis looks easier to integrate.

1

You cannot avoid the cost of a lookup: at one point, you will have to perform one if only to see if the sender is blacklisted or not.

So, your best option is probably to make sure a token lookup is quick enough to handle the load.

However, you should still keep a trace in your DB of invalid attempt with associated source. Such a trace should make it easy to check if a specific IP has a larger than acceptable number of failure recently. Check this first in order to limit token-guessing to a minimum.

1

If in generating the page you add a hash token based on timestamp plus a secret then by including the timestamp and token in each request you can make it harder to craft attacks. The token can be checked without recourse to the database. Any request with a timestamp that is too old should also be rejected.

If this is a one-page app or similar where the page may not get fully refreshed very often then you can in your web service return a new hash token and timestamp in the response to any authenticated request.

0

You might try to use fail2ban or similar software and implement a "request limit" rule.

It will be based on the IP address but you will not need to have a check in your database for every request.

Moreover, when an IP will be blacklisted, it will not reach your webservice anymore as the firewall will block the incoming request before.

3
  • May be interesting, but how can i tie this to my IIS ? My webservice doesn't generate any log like apache does.
    – Fortune
    Jul 8, 2015 at 14:58
  • Unfortunately, this is recursive: in order to implement a limitation, you need to perform a DB lookup. It is only useful if checking the request token is more expensive that a DB lookup (it's good for preventing someone hammering your login API, for instance)
    – Stephane
    Jul 8, 2015 at 15:06
  • @Fortune, I read a post from a guy who did this (fail2ban) on windows with a vbs script. It seems that Stephane answer might be more useful to you as I assumed you were using Unix based server (don't ask me why :))
    – r00t
    Jul 8, 2015 at 15:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .