PHP mailer . . . secure?

[metazai]

Here's a weird one . . . I'm webmaster of several sites, but two of them which use the PHP mail functionality to submit webform results have come under . . . well, I'm not sure if I can call it attack, but I don't know what else to call it. I'm getting repeated blank submissions -- blank, that is, except for the email field, which is always "<random characters>@" and My OWN domain name. . . several hundred of these over the last month.

The online forms in question are simple information-gathering forms, nothing secure, so I don't have any field validation on them. When I add that, I just get more submissions, but with gibberish in all the fields. Is this somebody's bot trying to get into my server? Does using a simple PHP mail script provide any information that might expose a vulnerability? I added a snippet to send me back an IP address, but I don't know what I can do with that, except report it to an ISP, but report what, exactly?

Any thoughts? Anybody ever hear of this kind of attack?

[sde]

reporting most likely isn't gonna do anything. if you are getting that volume of mail, then most likely it's a bot or some program.

the best thing to do in this case is probably setup an image verification number. by that i mean have php generate an image that has a number or letters on it, and have the user type in what the image has.

then, before you hit the mail function, make sure the number the user inputted matches what was on the image.

here's a tutorial i found real quick on google: http://www.phpnoise.com/tutorials/1/2

[metazai]

Cooler and coolest . . . I'll check it out. Still, what information could a bot possibly hope to glean from what should be server-side only code?

[DJMaze]

Image verification aka CAPTCHA will work but not if they realy want to harm you because these days, thanks to OCR, a lot of apps can read the image.

To secure your script is session handling probably a better option.

PHP Code:

<?php
session_start();
if ($_SERVER['REQUEST_METHOD'] == 'POST' && !isset($_SESSION['allow_post']) {
  die('You are bad');
} else {
  $_SESSION['allow_post'] = true;
}

Since search engines and most spam bots ignore session cookies they don't send the session details so they always start with a fresh new session and that way 'allow_post' is never set.
So we prevent access to POST data for mail sending thru a session and that way they never can send a email.

You could also email address verification if they pass this POST prevention and if they still bug you after that something else is probably wrong.

[sde]

hmm good thinking, here's an idea that wouldn't even require sessions. the simplest way is probably to check for $_SERVER['HTTP_REFERER'] and make sure it has the domain in it.

PHP Code:

<?php
if( !strstr($_SERVER['HTTP_REFERER'],"mydomain.com") ){
  // don't send
} else {
  // send
}
?>

bottom line is that images can be read, sessions could be mocked, and referer headers can be manipulated, .. but will they re-program specifically for this site? probably not.

good luck.

[DJMaze]

yeah HTTP_REFERER is also a nice one.

Another one to use is an md5(remote_address) and use that md5 as a cookie name, when they switch IP they have to re-evaluate the code, but this would lock out a lot of AOL users since AOL changes your IP every minute.

[idx]

You could also do the easy honeypot link thing. Not sure how well it fares these days..

-r

[DJMaze]

or javascript <input type="button" onclick="submit_form();">

[metazai]

Thanks to you all . . . a few questions:

Sde . . . how does your script work? What does it do, and how do I implement it?

idx . . . what do you mean by "the honeypot link thing"?

[sde]

in the piece of code that uses the mail() function ( after the form is submitted ) , just add that check. you can make it error however you want ( silently fail or show them a message it failed ) , but if they pass the check, then your mail() function will go where the // send comment is.

[idx]

Basic idea is that you put a link on the page before most of the other links and if it gets a hit you block the IP (or whatever seems sensible) for a period of time. Naturally you give human visitors a way out.

Here's an example:
http://www.sqlite.org/cvstrac/wiki

Starting with the javascript submit might not be a bad start. It's probably the quickest way to stop the dumb spiders.

-r

[sde]

i don't get that example.. where are we supposed to look on that page?

[idx]

The honeypot link to the left of "attach".

[sde]

that's pretty cool.

[DJMaze]

it doesn't have to be a visible link either.

I log bad bots thru a hidden href http://dragonflycms.org/ (view page source and look at the bottom for: trap_crawler
You will get logged in
http://dragonflycms.org/trap_crawler/blacklist0.dat (unknown agents)
http://dragonflycms.org/trap_crawler/blacklist2.dat (know agents but probably malicious)

It seems to work so i gonna start a banning system with it