I have hard coded the email address to whom it is sent to. So that's
good. I like the token idea. So let me see if I get this. I'll use
sessions variables. The form loads and sets a session variable which
is stored in a hidden input tag in the form. Upon submission, the
processing part of the form looks at this field, cross checks it
against the session variable, and sends if it matches and doesn't
send if it doesn't (which includes no session variable at all). After
processing (sending) the session variable is deleted. This makes it
so anyone trying to go directly to the processing part of the script
to send their own stuff will not be allowed through. Is that it? I
like it.
Mark
----------------
On Nov 21, 2006, at 11:28 AM, Errol Sayre wrote:
1. How do I know if my php injection filter is working and the
spam is only being sent to me (web master)?
I'd suggest that you hard code the send address on the form (as
opposed to using a request variable). If you need your script to
provide services to multiple forms, then provide a white-list of
acceptable recipients that the script is allowed to email to.
2. If the spam is only being sent through the form, and they are
spamming only one email at a time and it's only coming to me, how
can I stop that? I can't imagine they are sitting at their
computer and typing/pasting the spam into the textarea, coming up
with a fake email address, and clicking the send button. It's got
to be an automated thing. So is there a way to test to make sure
that the email address is good or that the form is actually being
typed by hand by a person?
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).
Second, I'd suggest that you don't really have to worry about PHP
injection unless you actually execute php code from the request
data. This would be done using a function like eval() or by
including a file. Most likely you aren't doing this and I suspect
you're thinking about SQL injection rather than PHP injection.
Having said this, I recommend always using single quote strings
when possible and appending variables to the string ('this '.$is.'
the better way') rather than using double quotes with variables
directly in the string ("this $is not the better way"). This
doesn't directly protected against injection, but it does prevent
the possibility of any future exploits involved with the way PHP
processes double quoted strings.
These two steps will pretty much guarantee that folks are only
sending the email through your form and that it is only going to
who you intend it for.
Errol
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Web-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/web-dev/email@hidden
