Re: Secure Form Script?
From: Peter H. Lemieux (phl_at_cyways.com)
Date: Mon, 10 May 2004 13:45:21 -0400 To: email@example.com
Soner Eker wrote:
> Check this; http://www.zapyon.de/spam-me-not/index.html
I don't think textual obfuscation will work as a spam defense in the
long run. As the author observes, if spammer robots begin applying
different encodings to mailto: URLs, this approach will fail. Content
analyzers like SpamAssassin already apply such transformations to
inbound messages exactly because spammers use many kinds of textual
obfuscation in their messages. The big-time spammers are pretty
sophisticated so I would think "mainstream" address harvesters will be
rewritten to thwart this method soon.
>>Victor Daniel a.k.a the MacNut wrote:
>>>I'm looking for a secure form script to use instead of email links on my
>>>website. One that can't be easily hijacked to send spam messages to
Can someone point me to a discussion about the issues involved with
hijacking web forms? In the applications I write, the destination address
is usually stored on the server, either in the script itself, or in a
configuration file, or in a database. I don't see how someone could use
such a script to change the destination address and point it at a list
of addresses belonging to spam victims.
I can see how the problem would arise in more generic scripts, where the
destination address is often stored as a hidden INPUT field. Extending my
argument about the sophistication of spammers, we might envision a "form
harvester" that identifies exploitable forms using obvious fieldnames like:
<INPUT TYPE="hidden" NAME="destination_address" VALUE="firstname.lastname@example.org">
Once you find one of these, I can see how you could write a program to send
messages to thousands of different addresses simply changing by the
destination value and POSTing the form again.
Obfuscation in this more advanced context might make some sense. You might
want to name the field containing the destination address something unusual
(an MD5 hash might do) and apply some form of encoding to the address itself
to hide its user@domain format. That way "form harvesters" would be less
likely to identify your form as exploitable.
Still I'd prefer a system where the addresses are stored on the server. A
simple method for handling the generic case would be to use an MD5 hash as a
key to identify the destination address from a database on the server. Then
the input form would read:
<INPUT TYPE="hidden" NAME="idkey" VALUE="f728d3f78c4f9fb27cdadd489b628616">
With MD5 hashes, the chances of a spammer being able to identify even one
other valid key knowing a published one is vanishingly small.