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 (
To unsubscribe, visit:

Reply via email to