[thelist] spammers - perpetrators

Bob Meetin bobm at dottedi.biz
Fri Jan 25 09:41:33 CST 2008

See my comments/update at end...

Phil Turmel wrote:
> Bob Meetin wrote:
>> I have a spammer faking identity and emailing me crap like:
>> 	From: Neophytos Neophytos  
>> 	Email: IacovosFewrte64 at gawab.com 
>> 	Subject: Neophytos 
>> 	Website: http://fast-food.ophyu.com 
>> 	Problem: 
>> 	Request details: 
>> 	very well made it .All information on this site is represented
>> 	<a href=http://fast-food.ophyu.com/fast-food-nation.html>
>> The form that I used to use to collect feedback doesn't even look like 
>> that any more.  I changed some of the line words (Website is not there), 
>> so I don't know where this one is coming from.
>> With a second problem a couple times I've found some spam entries in the 
>> login, email or name fields of a table.  The program that folks use to 
>> register both checks for garbage like: http, www, angelfire, porn, 
>> common nasty words and will reject submissions.  I also include a simple 
>> math question. 
>> Suggestions?
> Hi Bob,
> Common problem, unfortunately:
> Comment/Form Spam
> Spammers try to hijack comment forms not just to send YOU spam, but to
> use your server to spread it further.  If your form's target script
> doesn't sanitize the subject field, or offers a variety of To:
> addresses, the script might be tricked into mailing the spam to other's,
> not just the intended recipients.  If the comment form is used with blog
> or other public web-site, then visitors to the site also see the spam.
> Spammers especially like forms that ask for a return e-mail address, in
> the hope that your script automatically sends an acknowledgement via
> e-mail.  They'll put a target e-mail address in the 'from' variable.
> You aren't seeing the correct format for these emails because the
> spammer isn't actually opening your blank form.  They are just
> submitting the GET or POST action directly (no real web browser on their
> end at all).
> http://www.google.com/search?q=comment+form+spam
> Spammers generally don't hunt for vulnerable websites by hand.  They
> typically use robot scripts that look for forms on any page they
> encounter.  The robot script notes the input field names and guesses
> which ones are the from, to, and subject lines.  Everything else is
> treated as a body field, in the hopes of getting through.  Your second
> problem is most likely caused by a spammer's script trying to send spam
> through your registration form, and your registration program isn't
> sophisticated enough to catch all the evasive maneuvers.
> In any case, there are some best practices to follow:
> Include a hidden field on every form that contains a session-based
> random token.  Check for and change the token every time a form is
> actually submitted.  ANY form!  Not just comment forms.  Especially
> login forms.  If a form is submitted with no session, no token, or wrong
> token, display a fresh blank form and log the IP address as a likely
> spammer.
> Check all variables submitted for reasonableness... If a userid is
> supposed to only have letters and digits, reject anything that has
> anything else.  Where you are expecting an email address, use a regular
> expression to make sure it is syntactically valid.  Subject lines should
> be only one line, and no more characters than the maxlength on the input
> field.  If you find a newline or carriage return in the subject, it's
> almost guaranteed to be a spammer.
> Never send an acknowledgement via e-mail.  Use the form script to
> acknowledge a valid submission right on the web.  Never accept actual
> To: addresses in submitted variables.  If you must have multiple-choice
> To: addresses, use a numeric index on a combo box, and look up the
> numeric index in your script.  Don't put any submitted variable into a
> database if any check fails.  Always use parameterized queries or the
> equivalent in your language of choice.
> If you do all of the above, and still have an objectionable amount of
> spam coming to you, add some form of captcha.  (But only as a last
> resort, as accessibility standards can be tough to meet when captchas
> are involved.)
> Happy Googling,
> Phil
This is an older thread, so I didn't strip out the original problem or 
Phil's suggestions.  It took me a while to get back to this. 

I like/liked the idea of sending an email acknowledgement but if it's a 
vulnerability then it goes south. 

About the session-based random token - I set up a randomly generated, 
hidden variable that is regenerated, every time the form is accessed, if 
it does not exist the form will not submit.  Is this what you are 
saying?  Is it adequate to check that the variable exists or must I 
check that the variable matches when the form is submitted?

Someone, perhaps Joel, said to test to make sure that the post is coming 
from the website in question.  How would I go about that?  This is 
shared hosting so the IP address of the server won't be absolute, but 
undoubtedly a start.

About the database injection stuff, it is probably due to the above and 
not qualifying the integrity of the content thoroughly enough.  That 
seems easy enough to solve.

Much thanks, Bob

More information about the thelist mailing list