PDA

View Full Version : E Mail Forms and Preventing Spam


fwr1000
08-20-2007, 06:49 PM
I think I have read here in the past that Ramandeep's tutorial and scripts will not prevent "injection attacks" to distribute spam. However, since it's a PHP form, is it correct that a spam bot will not identify the "send to" (i. e. the address the form will be sent to as a result of clicking the Submit button) email address as it's in the PHP file?

Thnx
Fred

domedia
08-20-2007, 07:19 PM
That has never been an issue, and you are perfectly right.

"Injection attacks" is not about the security of your personal email, but bascially means that the spammer use your server to perform sql/script tasks.

http://en.wikipedia.org/wiki/Code_injection

fwr1000
08-20-2007, 10:57 PM
Thanks Dom. I believe I now understand about the injection attacks. As my site does use any type of a DB, the form should not cause any issues.

Fred

domedia
08-21-2007, 12:41 PM
Fred, it's not isolated to using a DB. Is your form using PHP to generate an email? I'm not a programmer so I can't give specifics I'm afraid. Anyone else?

fwr1000
08-21-2007, 12:53 PM
Yes, its using PHP to gen the e mail. I'm using Ramandeep's tutorial and scripts from here on the DW Club tutorials.

Fred

davidj
08-23-2007, 08:16 AM
an injection attack arise when someone manipulates a hole in your SQL. SQL based attacks are used to gather info from a table or to bring down your db. The latter is easier.

when you write sql the syntax is as follows...

SELECT * FROM TABLE WHERE USER_ID='$VAR'

$VAR is the contents of a formfield

in the form field you could write this


'; drop table user .........'


as you can see i start the form entry with a single quote then terminate the command with a semi colon. I then inject my own code which in this case is to drop a table rendering your db useless

the SQL would look like this when i submit the form

SELECT * FROM TABLE WHERE USER_ID=''; DROP TABLE USER

as you can see my first single quote completes the USER_ID query which would return nowt which is ok because im not bothered what comes back. All i am interested in is to pass a command to the SQL engine which it executes.

this is what is classed as an injection attack

edbr
08-29-2007, 09:59 AM
what is the best defence against this?

davidj
08-29-2007, 10:02 AM
good data validation

check all input and strip anything that could be suspicious

also make sure the connection account cant drop tables which you can configure from your db access rights