Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hello. I'm developing a payment system where I'll be using PayPal IPN. Its to an e-commerce sites selling lots of goodies.

However, just recently my db was flooded.

My current process is this:
1. user browses my site for a product with a product ID and decides to checkout
2. script validates form (checks if the product is in stock etc.), and then enters the purchase information inside a database with a field called 'paid_or_not'
3. once someone signs up and pays, PayPal will notify a script of mine and this script will then update the product to be 'paid_or_not' status to TRUE.


All is well with this process until someone does something unintended. Of course this goes with many things...

Now the user was able to flood my database by either refreshing many times at checkout or building a script to do it. It would create many fake product info inside my database. Whats the best way to prevent this?

I thought about cookies, but didn't like the idea (can be disabled). I also thought about a simple IP throttle technique?? Would this be good? Or would it be losing on those on AOL, shared proxies, etc.? Perhaps a IP and HTTP_USER_AGENT check? Any light on this topic is welcomed :)

Thank you

Replies are listed 'Best First'.
Re: A good way to prevent "spam flooding"?
by varian (Chaplain) on May 26, 2007 at 07:34 UTC
    Throttling etc is not a consise solution against a database flood, it merely slows down the impact. It's better to prevent floods by maintaining 'state' information on the client, there are some common techniques and e.g. encoding session status in the URI is a way to avoid the need for cookies.

    Should you suffer from re-posting data problems then you can use the session state info to prevent such (e.g. hidden field with sequence number) or look at solutions discussed in this thread or this thread.

Re: A good way to prevent "spam flooding"?
by moritz (Cardinal) on May 26, 2007 at 06:42 UTC
    It seems too simple to ask - but are you deleting old entries after a certain time?

    If not, you should define a timeout, and run a cron job twice a day that clears all old entries in the database.

Re: A good way to prevent \"spam flooding\"?
by perleager (Pilgrim) on May 27, 2007 at 07:07 UTC
    Ran into a similar task a few months ago.

    I was able to find this thread that I ended up bookmarking.

    Hope this helps, Reload/Repost Disable

    Cheers, perleager
      Hey, that thread helped me understanding the logic to prevent the refresh duplicates, but in the it still not bullet proof? Wouldn't it be really easy for someone to just add a random generated session id and tag it on the session_id parameter, and keep making form requests to your validation script. The validation script will always receive different generated sessions, thus making it really easy to flood your directory?

      Perhaps, add a IP field and only allow 5 max request per? But then someone can trick the IP or perhaps connect to a list of proxies and take turns 1 by 1?

      Theres really no reliable way is there?
        thanks for replies....that thread also helped me a bit better. I guess someone will have to build some bot to do what your talking about? Its doesn\\\'t concern me too much security wise and I\\\'m just over worrying about it. also what did you mean by flood your directory?
Re: A good way to prevent "spam flooding"?
by Anonymous Monk on May 27, 2007 at 03:40 UTC
    Hi,

    Would a pseduo random number be good enough?
    my ($confid); my @passset = ('a'..'z', 'A'..'Z', '1'..'9'); for (my $i = 0; $i < 16; $i++) { my $randum_num = int(rand($#passset + 1)); $confid .= $passset[$randum_num]; }


    I also do not understand the point in maintaining a session state? Can't someone keep generating new sessions and use it over and over again?

    Am I worried too much? Who cares if theres 10,000 unnecessary records, it'll be deleted in 3 hrs (I do run a chron script deleting rows with expired time). ?

    thank you