Re: Newbie php problem

Beauregard T. Shagnasty wrote:

Tim Greer wrote:

Beauregard T. Shagnasty wrote:
Tim Greer wrote:
[snippage occurs]
Nothing would and that wasn't the intent of the reply. I said that
it would stop a lot of bots and (probably) the search engine
spiders.

Search engine spiders don't "submit" the form, so there is no worry
there.

No kidding. The OP said that their script would send email without
any submission (being blank emails they received),

This part confuses me. How could any contact form be "submitted"
without
some kind of human interaction?

A few ways. One is that his HTML form has a link that points to a
mail.php page (example name) that just shoots off an email via the
mail() function. If a search engine follows that link, it will send a
blank email. Another common way is that spam bots will hit commonly
named mail scripts at common locations, hence the blank emails the OP
receives. Of course, another way is that web surfers on the OP's site
are testing it and just pressing a submit button without filling
anything in (but that would indicate human interaction).

Even spambots are a type of human
use.

Not really, and that depends on your definition. If you mean a human
had to create it at some point, yes. However, many will iterate
through IP ranges, hitting common paths and names, and don't have to
have a human propagate it or specify a target site. I don't see the
purpose of debating this. The points I made were very clear. Once you
start debating that everything has to have a human involved at some
point, when we're talking about spam bots (not a spammer's script they
are running manually), it's probably best to just read what was said
and consider accepting it for what it is. There's no purpose to start
debating about trivial details.

If there are any other readers here who think it is possible for
a contact form to "submit" by any means other than human interaction,
please chime in.

A script (an automated one) known as a spam bot that hits form mail
scripts, is just like a script that tries to auto-exploit known
vulnerable scripts, which doesn't require specific IPs or domain names
to be specified. Those scripts are self propagating, even,
compromising some site's scripts, installing itself and then running on
a new site/server and trying to propagate itself further. I'm not
saying all spam bots do this, but it is a spam bot (i.e., automated
submissions). Even if a human initiated the spam bot script's process
on a server, it's still automated and doesn't have to only target only
specified sites. For example, spammers aren't likely sitting there on
google searching for every site manually that their scripts target.

which happens when a search engine spider "hits" the page (i.e., no
submission).

None of my contact forms have ever generated their action scripts by a
search engine visit.

So? You're not the OP. The way they have it set up, it's perfectly
possible that it was a search engine that enacted their mail function.
This has nothing to do with "your" contact forms.

A contact form (page) "doesn't really exist" until someone or
something actually visits the URL.

Sure it does. If you mean it doesn't exist to a "search engine" knows
it's there, then how to you think a SE spider works, when it
crawls/maps the site? I.e., perhaps that's how their form mail script
is being called (the one the OP has the form submit to -- since they
don't force any fields for it to email -- hence the blank emails).
Their form with the form fields itself, doesn't need to play a role,
other than providing a link to the search engines to follow (possibly).
I never said this *is* what is happening, the OP suggested it, and
depending on their set up, they might be right. Since requiring the
fields before it runs the mail() function portion of the script would
resolve the issue with search engines causing if (IF that's what's
happening), and since it's something they should want to do anyway, I
don't see the problem -- it really doesn't matter if that IS what's
happening, because it would fix that, too.


I'll snip a bunch more because it doesn't make much sense to me.

What doesn't make perfect sense? Do you have any specific questions?


There's no way to prevent a spammer that is manually trying to submit
to your form mail script, but you can easily prevent an automated
spam submission. Indeed, the field names (or the uniqueness of them)
wouldn't be relevant to that aspect. You'd want to use unique
sessions per request, per IP (being dynamic and unguessable), which
will expire in a short time.

None of my forms use sessions, IPs, etc.

That was just some suggestions of an effective way to prevent abuse of
your form mail scripts, since you said a spammer was abusing it and
that moving it didn't help (and that they were trying to use some
zombied network of infected systems to have people submit). Perhaps I
misunderstood you, but it was a method to prevent automated
submissions.

I occasionally get a visitor
who fills out and submits, only to realize an instant later they
forgot a bit of comment, so they go Back, edit and resubmit. I see no
reason to penalize them.

Who is penalizing them? The session for their request doesn't time out
too soon and it isn't removed until they specifically submit without
errors. Putting in some kind of limit only prevents abuse. As I said,
x number of submissions per hour or day. It would be 5, or 20, or 100,
whatever you think is appropriate. This was a method suggested to
prevent a spammer from using the session they have to automate
submissions, if that was a problem... and also to prevent it from being
a problem by being proactive.

It does not happen often, because the action
script takes them to a new page, showing the results of their
submission.

Okay.


In addition, once the submission for that request has been made, the
session is removed and a new one for a new request must be created.
In addition to that, you would implement a means to have a captcha in
an image code that must match the requestor's IP and session.

Wot? None of my forms use CAPTCHAs and survive just fine. And those
CAPTCHA images are hackable/readable by the bots, or so it has been
reported elsewhere.

I was offering methods in response to:

1) You saying a spammer was manually checking your mail form, even after
you moved it and changed the field names.

2) In reply to this specific topic, where you said a quick and dirty
solution for the OP was not serving any purpose.

I told the OP that the solution has limits and a more evolved/advanced
script should be replaced, if they have issues with spam (and maybe
before they have any issues). The captcha was a suggestion if that was
a concern, in response to you saying it wasn't enough. Yes, some
captcha images can be parsed by certain tools to pull text from images
(I said this myself in the post you're replying to now). I also said
that, if it was a concern or problem, the captcha image could use
various methods to make it pretty much impossible for such a tool to
parse it, and certainly would make automatic submissions impossible.


Additional features would ensure that only one IP (unique requester)
could submit x number of times per hour or day, and any attempts
beyond 'x' would result in a block and no further emails or
processing (because saving processing is a good thing). That is a
for example, just some of the methods that are easily implemented,
which are pretty fool proof for any automated or zombied type of spam
bots.

Checking submitted results for carriage returns, inclusion of the text
string "CC:" and a few other tests are all that's required, as I see
it. Again, none of my forms are vulnerable to spambots.

For preventing your script from being the source of spam to other
people, yes, you would implement such checks. It shouldn't be just the
inclusion of CC:, but how it's interpreted by your script, just like
BCC or any other field one could pass before the header's subject,
including people trying to pass additional email addresses on the to:
line (separated by whitespace, semi-colons, commas), and so on. Anyway,
I must have misunderstood you, because I thought you said you had a
spammer trying to abuse your scripts. If not, disregard that aspect in
relation to your scripts then. Either way, the point was to protect
the script from abuse. Not just as a source of the spam, but so you
don't get "blank emails" or "spam emails" to yourself (being a spammer
might just be hitting your script not realizing it's only going to
you), so you want to put in some methods to prevent that and to add
limitations. A lot of spam bots don't care or check, they just hit it.
The OP said they already have a problem with blank emails due to lack
of checks, and checking to ensure your script isn't the source of spam
is a great idea (which is part of the suggestion of a more evolved
script), but it would still result in blank emails or them getting spam
themselves, if they don't make those other changes, too. No
disagreement about preventing the script from being the source.


Changing the name of the file, field names, etc. is never a good
method. Security by obscurity is a bad idea.

I'll agree that obscurity doesn't always work - by itself. The file
and field names I mentioned were just to annoy this one persistent
guy.

I see.

Implement something like I have outlined in the previous paragraph
and you won't have to worry.

Yes, you would, in my opinion. Anyone else have a comment?

Why would you need to worry about something such as I had previously
outlined as a workable solution to prevent abuse of your script?
Obviously it wouldn't act as the source, if that's what you mean (being
that obviously captcha, timed sessions per IP, fields required, etc.
doesn't cover the aspect of secure coding to prevent being the source
of spams via CC, bcc, additional emails, etc. -- but that was certainly
accounted for as well -- I only outlined methods to prevent abuse to
you by an automated script, as that was the subject of this topic at
one point and that is what I was responding to). Is that more clear?

My spammer isn't automated .. but if he found that he could exploit
my form, you betcha he would automate it soon enough.

Right, and the OPs script was utterly vulnerable to an automated
attack (even if it would just be them that got the email). You are
correct that you can't stop a manual submission in most cases, but
you can limit it where they can't spam you (at least not to where
they can possibly automate it). You are welcome to view our contact
form and try and abuse it (I'm not kidding and I'm not being
sarcastic), if you want to see how the script I have coded for our
contact form works.

Thanks for the invitation, but I'll pass.

That's fine. I just figured you could visually see what I meant, since
you seem to think you'd still have to worry.

Granted, the generated number for the code could be parsed since I
don't have it distort the font/text or cycle the colors or add
background noise, but we didn't feel that was needed.

Font, colors, backgrounds would have nothing to do with form use.

Yes it does. They would to require a human to read it, and an automated
script that could use a tool to automate submissions. I specifically
said that the fonts, colors, background noise, size and distortions
were on the text on the *image* that was generated on the fly.

My
browser can certainly override your choice of HTML fonts and colors,

No it can't. You misunderstood. It wasn't talking about fonts and
colors on the HTML text, but the text in the auto-generated image (so
image tools can't parse the captcha -- assuming a more basic captcha
wasn't working effectively, if you had a lot of abuse).

because I might be a person with vision problems. How would your
action script determine that?

Like I said, it's an image in that example, not page text.

I had created a similar script previously that was alphanumeric, it
would randomly have different numbers of characters (say 6 to 10,
depending), cycling through different font types, colors, font sizes,
distortions (bending at different angles/waves of the text) and
background noises, but always readable, which made it impossible for
a program to turn the image's characters into text to automate an
attack or spam bot. However, again, we didn't feel that was necessary
in this case.

I have no idea what all that means, nor why the *appearance* of the
contact form could have anything to do with its action script.

The text in the _image_, *not* the page.

Don't get me wrong, I can appreciate you taking it further -- the OP
will only benefit from it.

If for no other reason than to show that any action script written
without extensive validation is vulnerable. ;-)

Of course. No one disagreed with that.

--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
.