Re: Newbie php problem
- From: "Beauregard T. Shagnasty" <a.nony.mous@xxxxxxxxxxxxxxx>
- Date: Thu, 8 Jan 2009 10:46:22 -0500
Tim Greer wrote:
Beauregard T. Shagnasty wrote:[snippage occurs]
Tim Greer wrote:
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? Even spambots are a type of human use.
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.
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.
A contact form (page) "doesn't really exist" until someone or something
actually visits the URL.
I'll snip a bunch more because it doesn't make much sense to me.
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. 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. It does not happen often, because the action script takes
them to a new page, showing the results of their submission.
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.
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.
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.
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?
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.
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. My
browser can certainly override your choice of HTML fonts and colors,
because I might be a person with vision problems. How would your action
script determine that?
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.
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. ;-)
I'll snip the rest...
--
-bts
-Friends don't let friends drive Windows
.
- Follow-Ups:
- Re: Newbie php problem
- From: Tim Greer
- Re: Newbie php problem
- From: Geoff Berrow
- Re: Newbie php problem
- From: Floor
- Re: Newbie php problem
- References:
- Newbie php problem
- From: Floor
- Re: Newbie php problem
- From: Tim Greer
- Re: Newbie php problem
- From: Beauregard T. Shagnasty
- Re: Newbie php problem
- From: Tim Greer
- Re: Newbie php problem
- From: Beauregard T. Shagnasty
- Re: Newbie php problem
- From: Tim Greer
- Newbie php problem
- Prev by Date: process to add PHP 5.2 to an existing 5.1.6 install?
- Next by Date: Re: Newbie php problem
- Previous by thread: Re: Newbie php problem
- Next by thread: Re: Newbie php problem
- Index(es):
Relevant Pages
|