Many of the older techniques for sending Spam out via remote servers either involves searching for open relays, using brute-force attacks against a server (to guess a username and/or password) or exploiting by bugs in scripts (or on a service).
However, we have recently come across a new style of attack - injecting extra data into custom-written contact forms.
Many custom-written contact forms do not properly check the data being sent to them, normally just inserting it straight into the e-mail to be sent. For example;
<?php $to = 'test@example.com'; $from = "From: ".$_POST['from']; $subject = 'Test E-Mail'; $content = $_POST['message']; mail($to, $subject, $content, $from); ?>
would just add all the information from the HTML form straight into the e-mail, regardless of what was sent.
In this case, if someone send the following as part of the From field:
test@example.net Bcc: testing@example.org, tester@example.org, tested@example.org
the e-mail would look like:
From: test@example.net Bcc: testing@example.org, tester@example.org, tested@example.org To: test@example.com Subject: Test E-Mail The message received from the website goes in here...
Although the e-mail would still be sent to you, and it would just look like some Spam or junk. The extra Bcc field in the header however would tell our servers to send to mail to many other people as well (here testing@example.org, tester@example.org, tested@example.org), without you knowing!
There are two options - the basic method or the full method. Which one you use depends on the field being checked and/or your level of programming experience.
The basic method just involves making sure that there are no \r or \n characters in the e-mail. This prevents extra lines from being added into a header field (and therefore should be added to those that add into headers). Although, for some fields, such as Subject, this may be all you can check for.
The more complex, full, method is be actually checking the format of the response to make sure it's valid for it's purpose. For things like a name, this could be a just alpha-numeric (A-Z and 0-9) characters, along with some publication (such as '-', '_', etc., but not '@'). For e-mails, you may want to run a full check to make sure the e-mail address is in the correct format, and therefore will be valid when you pass it to the server to be delivered.
There are many articles to check e-mail addresses in just about any language you may write your site/program in:
If you have any questions about this, would like your code checked, or are updating your code and have become stuck, please Submit a Ticket to our Support Team who will do their best to assist you.
 Comments |
 Add a Comment |
My regex is '/^[^@\s]+@([-a-z0-9]+\.)+[a-z]{2,}$/i'
that is:
a) multiple characters before @ that aren't whitespace or @
b) - OR a-z OR 0-9 followed by a dot, taken multiple times
c) ending in a sequence of 2 or more letters (eg to allow for .info domains and new primary domains in future). Many regex are wrong here and only allow 2/3 chars for last part of domain name.
d) it's all case insensitive
As these articles above show Regex is not perfect at coping with all types of email address. There is a danger than you will simply get bogged down with attempting to validate an email address to which there is no real regex to fix it for all circumstances.
The problem with form field injecting may be better approached by simply stripping the characters you do not want. For example, removing more than one '@' or removing slashes.
I don't have the code handy maybe someone can post something.
(06:59 May 5th, 2006)