CODEWITHSUNDEEP
pythonsecurityflaskspam-prevention
chrickso
chrickso

Reputation: 3034

Leanest way to prevent scripted abuse of a web app?

I am running flask/memcached and am looking for a lean/efficient method to prevent automated scripts from slamming me with requests and/or submitting new posts too quickly.

I had the thought of including a 'last_action' time in the session cookie and checking against it each request but no matter what time I set, the script could be set up to delay that long.

I also thought to grab the IP and if too many requests from it are made in x amount of time, deny anymore for so long, but this would require something like redis to run efficiently, which I'd like to avoid having to pay for.

I prefer a cookie-based solution unless something like redis can prove it's worth.

What are the 'industry standards' for dealing with these kinds of situations? What methods come with the least amount of cost/performance trade-offs?

Upvotes: 4

Views: 1378

Answers (3)

MarkG
MarkG

Reputation: 1869

An extremely simple method that I have used before is to have an additional input in the registration form that is hidden using CSS (i.e. has display:none). Most form bots will fill this field in whereas humans will not (because it is not visible). In your server-side code you can then just reject any POST with the input populated.

Upvotes: 0

Jonathan Vanasco
Jonathan Vanasco

Reputation: 15680

You should sit down and decide what exactly your "core" problems in the scenario of your app are, and who your likely users will be. That will help you guide the right solution.

In my experience, there are a lot of different problems and solutions in this subject - and none are a "one size fits all"

  • If you have a problem with Anonymous users , you can try to migrate as much of the functionality behind an 'account wall' as possible.
  • If you can't use an account wall, then you'll be better off with some IP based tracking, along with some other headers/javascript stuff. Going by IP alone can be a disaster because of corporate proxies , home routers, etc. You'll run the risk of too many false positives. If you add in browser info, unsavory users can still fake it - but you'll penalize fewer real users.
  • You might want an account wall to only serve as a way to enforce a cookie , or it might plug into the idea of having a site identity where experience earns privilege
  • You might want an account that can map to another trusted site's account. For example, I generally trust a 3rd party account binding against Facebook - who are pretty decent at dealing with fake accounts. I don't trust a 3rd party account binding against Twitter - which is largely spam.
  • You might only require site "registration" to need solving a captcha , or something else mildly inconvenient to weed out most unsavory visits. If the reward for bad behavior is high enough though, you won't solve anything.

I could talk about this all day. From my perspective, you have to solve the business logic and ux concepts first - and then a tech solution is much easier.

Upvotes: 2

mensi
mensi

Reputation: 9826

There is no way to achieve this with cookies, since a malicious script can just silently drop your cookie. Since you have to support the case where a user first visits (meaning without any cookies set), there is no way to distinguish between a genuine new user and a malicious script by only considering state stored on the client.

You will need to keep track of your users on the server-side to achieve your goals. This can be as simple as an IP-based filter that prevents fast posting by the same IP.

Upvotes: 4

Related Questions