Capchas can't hold off any decently smart robots, anyone doing their research can find at least 3 tools that will defeat various capchas. For example pwntcha is one, Dan Kaminsky did a talk at black hat and defcon 16 on pwning audio capchas (and a lot of even good ones will offer audio as an option) bottom line is capchas don't really hold off determined robots. As far as referrer goes, yes it can be easily spoofed, no there is no really built-in way to test it, yes the script can still be made pretty secure. But here are two ways i can think of to help prevent bots from taking over your email script (ideally use them together): Tokenize your URL, build a token based on the http_referrer amongst other things, just make sure you use something that would identify a normal user consistently, and say only allow one token say 5 emails a day. When referrer and token don't match, dont send an email. Use a strong hash algorithm, like sha to generate the token, and salt it, and add a something at every level. For example, use http_referrer for user piece, some random string of 32 characters hard coded into your script, and if you touch a DB, something you pull when you validate the email, from your db (not the email itself, something randomly generated when that email was added). This way, having even 2 bits of information, you still can't reverse the hashes. Note to not use a random value, you want a consistent hash that you can check. Set a timeout for your script, that is pause your server side script for 10 seconds before sending an email, and pop back a confirmation before actually sending the email after that (use a session to make sure they are not bypassing that bit). This forces any script to confirm their action, meaning they will have to execute for at least 10 seconds, meaning that they can only send 10 emails a minute, and for anyone who wants to do mass spamming with your script, that's unacceptable. By the way, don't set this time in JS, set an ajax request that actually needs data that gets pulled from the server to continue (like a secret random password stored in the session), just a simple time-out won't solve the issue. Both used together should provide for a good way to stop any useful spamming done with your script. ~ Alex -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
