On Mon, 27 Feb 2006 18:07:51 +0000, Geoff Berrow put finger to
keyboard and typed:

I'm not Jon, but I think that the main problem with your approach is
that it's starting from the wrong end. For a start, cleaning the
content before generating the email is a little pointless. If you've
got that kind of stuff being injected via the form, then don't clean
it - drop it and don't bother creating the email at all. It can have
no legitimate purpose, so why even put yourself to the bother of
getting the spam? And, if you're dropping the data rather than
cleaning it, you can focus on looking for the one string that is never
necessary in a legitimate mail, but always present in an exploit
attempt: a newline. A newline in a form field that doesn't come from a
<textarea>? End of processing. Full stop.

Secondly, looking for specific taboo strings in the input runs the
risk of missing one that you forgot to code for. A better option is to
construct your mail data in such a way that no user-entered data gets
anywhere near the headers. Instead of a free-form subject field, have
a selectable list. Don't set the email "from" to be the submitter's
address - hard-code it to be one of your own, and put the user's email
into the body. The aim is to keep user-generated input and mail
headers completely separate, so that nothing the user does can affect
the handling of the mail.

Mark
--
Visit: http://www.ukcommunityradio.info - Community Radio in the UK
Listen: http://www.goodge.co.uk/files/dweeb.mp3 - you'll love it!

"Krustov" <krusty@krustov.co.uk.INVALID> wrote in message
news:MPG.1e6d251edc22568b98ad25@news.newsreader.co m...
They tend to use character substitution so that won't work.
How e do it is to restrict sending of mail to email addresses @domains which
exist in our localdomains file.
This means that even if they could inject anything it would only go to us.

There is a new form of spam though.
Someone is sending legitimate messages automatically via contact forms to
the intended recipient advertising their web sites.
Therefore you can't report them to the ISP as the originating IP is actually
your server.
It gets very annoying.


--
Gordon Hudson || Hostroute.com Ltd
e-mail:ghudson [at] hostroute.net
http://www.hostroute.co.uk/resellers Host 5 web sites for £9 per month
http://www.nameroute.co.uk/ Domain Names with free hosting and email
http://www.myqth.co.uk/ 3000MB of web space for £29 per year

<uk.net.web.authoring , Gordon Hudson , gordon@usenet3.hostroute.co.uk>
<440376e5$0$1170$5a6aecb4@news.aaisp.net.uk>
<Mon, 27 Feb 2006 22:02:09 -0000>

Currently writing a guestbook and entrys made are only sent to myself .

The email address is in the php config file and the guestbook entrys are
only sent to myself - do I have any spammer injection problems to worry
about ? .


--
(c) The Amazing Krustov

In article <ttl602pnplfbc3a3g0q6atnfuus3l145p5@news.markshous e.net>, Mark Goodge wrote:
What he said. Trying to filter out "bad input" is almost always
fundamentally wrong. Write your code so that it always does the Right
Thing no matter what the input. It's easier, quicker and more secure.

Message-ID: <ttl602pnplfbc3a3g0q6atnfuus3l145p5@news.markshous e.net>
from Mark Goodge contained the following:

Would I need to check for \r\n, \r and \n ? Any others?

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011

Message-ID: <ttl602pnplfbc3a3g0q6atnfuus3l145p5@news.markshous e.net>
from Mark Goodge contained the following:

And then check the input is an item from that list presumably.

Yes I'm doing that
verify the email address - the mail contains a link which sets a flag in
the db when the user responds) as well as a copy for the administrators.

I understand that, and I like the idea of dropping mail where people are
playing silly buggers. I have a script on ckdog that someone
periodically has a go at. They don't get anywhere, but like you say, I
can do without the spam.

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011

On Tue, 28 Feb 2006 00:54:38 +0000, Geoff Berrow put finger to
keyboard and typed:

The form data is just a list, like this:

<select name="subject_id">
<option value="1">I wish to register a complaint</option>
<option value="2">Got any Os?</option>
etc

and then convert that to an actual subject line in the script:

$mail_subject = $human_readable_subject['subject_id'];

using a predefined array of subjects. If someone hacks the form, the
worst you'll get is a blank subject (although you could trap for that
separately, if you wanted).

If you're doing that, then you need to validate the email address in
some way before sending it. That's where you do need to do some
sanity-checking for valid formats before doing anything with it. But
it's fairly easy to trim an email input down to a valid address, as
it's a lot less free-form than other inputs. Checking that there is
one and only one "@" in the text, and that there are no spaces, commas
or newlines would probably be enough.

Also, it's wise to make sure that the mail back to the user doesn't
have any content other than your auto-generated data - it doesn't
contain a copy of anything else that the user has submitted via a
free-form text field. Otherwise, someone could use the form to spam
simply by putting someone else's address into the system and their
content in the text box.

Mark
--
Visit: http://www.MotorwayServices.info - read and share comments and opinons
Listen: http://www.goodge.co.uk/files/dweeb.mp3 - you'll love it!

Message-ID: <0cu702dpomhos6i8s75t4pepv9jl1f7fn3@news.markshous e.net>
from Mark Goodge contained the following:

For the newlines, would it be sufficient to check for the presence of a
backslash? I know there are various options, but they all seem to use a
backslash and I don't think it's a valid email character is it?


Ah yes, good point. So the mail I send back to the person who
legitimately fills in the form is just content that I want to send and
doesn't contain anything that they have supplied.

Unfortunately it's a requirement that I have to send the form details
back to the administrator, as a back up. I'll just have to send two
separate emails.

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011

Geoff Berrow wrote:

Don't send it to the "person who legitimately fills in the form"
at all.

Once the 'bots have found you, the "person who legitimately fills
in the form" will commonly look like a very long list of addresses.
And another a few minutes later. Etc. Just as soon as they've
figured out how to make your own contents appear as a mere
attachment to theirs (and it'll be abused even if that doesn't happen).

--
Nick Kew

In article <pm1802pj1233d340ne0gr1ro74kk00g23t@4ax.com>, Geoff Berrow wrote:
No, that's just the way PHP (and many other languages) are
representing non-printable characters. "\n" isn't how a newline
appears in the data, it's how you put a newline character into a
string constant in the PHP source.

If you want to strip newlines then stripping "\r" and "\n" is the
way to go (you don't need to strip "\r\n", of course, because that'll
have already been stripped by the previous two steps).

It is a valid email character, and it's important to note that in fact
*every* character in the range 0-127 is a valid email character. In
the real world of course I've got not much sympathy with someone who
tries to claim, say, newlines or character \x03 are a vital part of
their email address, but characters like "+", "-", "," etc can and do
crop up in valid email addresses.

Even Pedt's email address, which contains "@" characters in the user
part, is valid - disallowing more than one "@" is technically wrong
too (although again personally I'd probably consider it acceptable to
block that in a web form input).

The main problem appears to be that the way your form is coded, an
email address from the user can magically become something else,
such as other message headers or multiple email addresses. This is
what I meant when I said that you're doing it fundamentally wrong.
The cause for this I should imagine is that you're using the PHP
mail() function, which is standard for PHP in being utterly broken.