Re: Secure Form Script?

From: Peter H. Lemieux (phl_at_cyways.com)
Date: 05/10/04

  • Next message: Michael Rice: "Re: Secure Form Script?"
    Date: Mon, 10 May 2004 13:45:21 -0400
    To: focus-linux@securityfocus.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="spam-me@my.domain">

    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.

    Peter


  • Next message: Michael Rice: "Re: Secure Form Script?"

    Relevant Pages

    • Re: More on spam
      ... >> web archives can't obfuscated. ... and it is easy enough to figure out what level of obfuscation would ... If a human can read it, so can the spammers. ... `'` proud Debian admin and user ...
      (Debian-User)
    • Re: Removal of uk.religion.jewish, Fast Track fails
      ... But if someone like ...Banter mirrors Usenet to the web without any ... obfuscation, won't spammers pick that up? ...
      (uk.net.news.config)
    • Re: Removal of uk.religion.jewish, Fast Track fails
      ... But if someone like ...Banter mirrors Usenet to the web without any ... obfuscation, won't spammers pick that up? ...
      (uk.net.news.config)