Best way to prevent script abuse in a web application?

Question

I run flask / memcached and looking for a lean / efficient method to prevent automatic scripts from popping me with requests and / or sending new messages too quickly.

I had to include the "last_action" time in the session cookie and check every request for it, but no matter what time I set, the script could have been set for so long.

I also thought that I need to grab the IP address, and if too many requests from it are made in x amount of time, refuse more for it for so long, but it will require something like redis to work efficiently, which I would like to avoid to pay for.

I prefer a cookie based solution if something like redis can prove it is worth it.

What are “industry standards” to deal with such situations? What methods come with the least cost / performance trade-offs?

Answer 1

It is not possible to achieve this with cookies, as a malicious script may simply disable your cookie. Since you must support the case when a user visits for the first time (i.e. without any cookies), it is impossible to distinguish a genuine new user from a malicious script, only taking into account the state stored on the client.

You will need to track your server side users to achieve your goals. It can be as simple as an IP-based filter, which prevents fast wiring to the same IP address.

Answer 2

You should sit down and decide what exactly the "main" problems in the script of your application are, and who your likely users will be. This will help you find the right solution.

In my experience, there are many different problems and solutions to this issue - and not one of them is “one size fits all”

• If you have problems with anonymous users, you can try to transfer as many features as possible behind the “account wall”.
• If you cannot use the account wall, you will be better off with some IP address as well as some other headers / javascript. Only one IP address can be a disaster due to corporate proxies, home routers, etc. You risk too many false positives. If you add to the information about the browser, dubious users can still fake it, but you will fine less real users.
• You might want the account wall to serve only as a way to force the use of a cookie, or it could connect to the idea of ​​having a site identifier where experience gains privileges.
• You may need an account that can map to another trusted site account. For example, I usually trust a third-party Facebook account - which is pretty decent when dealing with fake accounts. I don’t trust a third-party Twitter account, which is pretty much spam.
• You may only need to “register” the site in order to solve the captcha, or something else that would be inconvenient to weed out the most unpleasant visits. If the reward for misbehavior is large enough, you will not decide anything.

I could talk about it all day. From my point of view, first you need to solve business logic and ux concepts, and then the technical solution is much simpler.

Answer 3

The extremely simple method that I used earlier is to have an extra login to the registration form, which is hidden using CSS (i.e. has a mapping: none). Most form bots will fill this field, while people will not (because it is not visible). In your server code, you can simply reject any POST with a filled input.