Re: Email spam - possible problem.

The message body of an email is separated from the headers... so you only need to be concerned about any of the inputs that come from the form and go into either the to, subject, or header arguments of the mail() function. I'd suspect that you're only using the form for the from email address.

On Nov 25, 2006, at 6:05 PM, Mark Wheeler wrote:

Hi Errol,

Sounds like I'm getting there. I've hard coded the "to:" email address, but the grep search for only one valid email address... that can be added. Would I need to look through form input or just the email form inputs?

Mark

-------------------

On Nov 25, 2006, at 11:19 AM, Errol Sayre wrote:

Ah, yes, this is what I was talking about when I said that this just adds another step that a spammer has to go through to use your script. But again, if you took the other steps to lock down your script (i.e. hard coded email addresses and grep search to ensure only one valid email address) you make the script basically worthless to a spammer. They have to use twice the traffic with the email only going to you.

On Nov 24, 2006, at 5:04 PM, Mark Wheeler wrote:

Hi Errol,

Yeah, I forgot to put that in the email. After the email gets sent, I did exactly as you stated about unsetting the session variable. The problem that I come up against is that if the spammer loads up the form into a browser window, look at the source code, find the input tag with the token value, plug it into his script and he can get through. Here's what I mean.

1. Spammer loads up my form.

2. Looks at source to get the hidden input tag with the token value in it.

3. Copy and pastes that input tag into his spam script.

4. Opens a new browser window and runs his script.

5. Mail goes through because the token is correct and the session variable is still active.

Does that make sense? Am I over-thinking this?

Mark

-------------------

You need to make sure that a token only gets used once.

This could be a simple as unsetting it in the session once you verify it is a valid session.

unset($_SESSION['form_lock']);

This makes it necessary to view your form each time they try to submit data to your script.

On Nov 24, 2006, at 2:37 AM, Mark Wheeler wrote:

Hi Errol,

OK, I tried to go this route, and I'm not sure if I'm doing it right. Here's what I did. The form loads and this happens.

<CODE>-------------------------

session_start();

.

.

.

$token = md5(uniqid(rand(),true));

$_SESSION['form_lock'] = $token;

.

.

.

<input type="hidden" name="form_lock" value="{$token}">

</CODE>-------------------------

Then when the form is submitted, I check the hidden field against the session variable like so.

<CODE>--------------------------

session_start();

if (!isset($_SESSION['form_lock']) || !isset($_POST['form_lock']) || $_SESSION['form_lock'] != $_POST['form_lock']) {

   header("Location: elistCE.php?action="">

   exit;

}

</CODE>-------------------------

Is this how what you were speaking about? It works, but all a spammer would have to do is load the form, look at the source code, find the input tag with the token value, plug it into his script and he can get through. Now am I over simplifying this or doing it the wrong way (not how you do it)?

Thanks,

Mark

----------------------------

On Nov 21, 2006, at 11:28 AM, Errol Sayre wrote:

One of the ways to protect an email form is to force the user to submit using a valid form. I do this like so, when the user visits the form the script creates the token and adds it as an invisible field to the form. When processing the submission the script looks for this token and verifies that it is still valid (this could be a file on the server, session variable, or database entry) and if it isn't valid I deny the input. This prevents a script from just dumping values onto your send email script (which is probably the source of the spam).