Not exactly marketing news but lets face it - we all manage web sites, even if it is just our personal ones. There seems to be a surge in automated attack being carried out on web site contact forms. Reports started flying in yesterday from our clients but soon newsgroup posts sprang up on the same subject. Basically these attacks revolve around the hackers injecting extra lines into your web site forms, in an attempt to send their own emails.

We were first alerted by clients who has received emails similar to this:

Sender Name: nonsense@yourdomain.com
Sender E-Mail: nonsense@yourdomain.com
Sender Telephone: nonsense@yourdomain.com
Content-Type: multipart/mixed; boundary=\”===============0536760457==\”
MIME-Version: 1.0 Subject: 210e1076
To: nonsense@yourdomain.com
bcc: attackers-address@domain.com
From: nonsense@yourdomain.com
This is a multi-part message in MIME format.–=============0536760457==

Content-Type: text/plain; charset=\”us-ascii\”
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

tzahlsalaitr
–===============0536760457==–

Web Enquiry: nonsense@yourdomain.com

I have changed the email addresses here to make it clear what has happened. The hacker has forced extra information into the form, in this case the 'Sender Telephone' field. This extra material is emphasised in my example above. This do by filling out the form fields with extra code, namely line breaks in HEX and new email headers. This code forms a second email message which they attempt to get sent via your PHP email script.

This second message will alert (by the Bcc. address) the attacker, letting them know the hack has been successful. They can then return to use your web form to send spam out to their targets.

Thanks to my friend and fellow SEO, Paul Silver, for asking the right questions at the right time and to Piers for the background information on this attack: SecurePHP: Email Injection.

Fixing This

Although we are not entirely sure this attack was successful, making sure that an attacker can not insert either line breaks (/r | /n) or ‘Content-Type’ information into your form fields would seem a sensible precaution. I have to thank Jeremy Keith for this solution.

Run this code on each form variable you are receiving through the POST, to ensure that this material is stripped out.


<?php
if (stristr($_POST["var_name"],”Content-Type:”) || stristr($_POST["var_name"],”\r”) || stristr($_POST["var_name"],”\n”)) {
$_POST["var_name"] = substr($_POST["var_name"],0,strpos($_POST
["var_name"],” “));
}
?>


The SecurePHP site offers a slightly different approach. Rather than stripping out the dangerous material, this script will cause the email script to fail if it is found in the form contents. The users would be given a notice on screen. I have modified this to include ‘Content-Type’ detection:


<?php
$from=$_POST["var_name"];
if (eregi(”\r”,$from) || eregi(”\n”,$from) || eregi(”Content-Type:”,$from)){
die(”Why Are You Hacking This Form ??”);
}
?>


• Subscribe to RSS
• Subscribe by Email