Comments on: Sending spam through contact forms

This solution doesn't apply

Gerd Riesselmann — Sun, 11 Jun 2006 13:45:29 +0200

This solution doesn't apply to the kind of spamming discussed here, since it is not about getting a set of links published on another one's web side as it is with comment spam.

Instead, this exploit is about turning a contact-form (or a comment form or actually any form that sends e-mails to whomever) into an open relay, that is: the form is used to send spam e-mails to thousands of other people.

This spam doesn't necessary need links, but could also be some plain text. Over here in Germany, for example, the extreme political right does e-mail-spamming capaigns ever once in a while.

That's right, but currently

Anton Titov — Fri, 02 Dec 2005 02:10:33 +0100

That's right, but currently spammers inject two new lines to all input fields of the forms. With this patch their scritps will need to be smart enough to find the from field, inject bcc there and be careful not to put new lines to other fields as sending will fail. The chances are that they will do this if my patch will be incorporated into PHP, but for a few months this will work. Actually I prefer it not to go to PHP sources, as this way my servers are protected from current spammers tools, and I have no problem maintaining patchsets for PHP as my mail function is already patched to include headers with sender's domain (I own a hosting company and need to know if my users are sending spam, which with mod_php is not quite possible). For last 10 days before applying the patch to all the servers I have 1000+ mails from AOL and few from SpamCop with complaints that spam was sent from my networks and now it is over. I know it is not a perfect solution, but it works currently, just like graylistig, which is also a working but easy to fool solution. Just warning users that their forms are vulnerable is not an option, there are at least 500 forms on my servers that was used to send spam, many of them are part of softwares like osCommerce (maybe outdated version), that fail to check input data. Convincing a user that he will need to rewrite/upgrade something working (for him) is not that easy, so for now the only solution for me is to try to patch PHP and I can go as far analyzing if part of additional headers came from POST/GET (maybe stripslashed) and to block mail if this part contains new lines - again not a perfect solution but it will work most of the time.

In general maybe it's a good idea for PHP to start accepting additional headers not only as string but also as an array of strings (and no one of them will be allowed to contain new lines) and to recommend this way of using it. After few versions to put a setting in php.ini that disables the old behavior and after few more versions to make it disabled by default. Checking $to and $subject for new lines should stay.

Hey Anton, that's cool.

Unknown — Fri, 02 Dec 2005 00:05:19 +0100

Hey Anton, that's cool. Actually the mail() function is definitly the place to stop this kind of attacks. Thumbs up for this! However, your patch doesn't cover the full story. The problem lies in the additional headers. Your patch

checks ... if additional headers parameter have two subsequent new line characters and in this case trows a warning and do not send the mail.

This is still vulnerable, I think. Here's why:

A from field is taken from user input and not verifyed agains injection code.
User enters "email@example.org%0Abcc: victim@example.org"
The application generates a header: "from: email@example.org\nbcc: victim@example.org"

The header is valid, nethertheless the attack was successfull. I myself stumbled upon this, when proposing a patch for Drupal. Unfortunately there is nothing to do against this, except of checking user input before passing it to mail(). I think this is a design flow in the mail() function itself. There really is no reason why the sender can not be passed as a parameter, at least optional.

I've developed a PHP patch

Anton — Thu, 01 Dec 2005 22:08:29 +0100

I've developed a PHP patch that fixes this at PHP level:

http://www.titov.net/2005/12/01/php-forms-spam/

Thanks Alastair, you're

Gerd Riesselmann — Tue, 22 Nov 2005 19:25:47 +0100

Thanks Alastair, you're right. I corrected both of them.

Also, I notice this, which

Alastair Battrick — Tue, 22 Nov 2005 12:35:39 +0100

Also, I notice this, which is just daft (the first line is effectively ignored):

$ret = str_replace("\r", "", $value); $ret = str_replace("\n", "", $value);

There is a parse error with

Alastair Battrick — Tue, 22 Nov 2005 12:32:42 +0100

There is a parse error with your function. An extraneous semicolon.

Thanks for writing it BTW!

Hello Dave! The thanks go right back for your initial work.

Gerd Riesselmann — Fri, 16 Sep 2005 22:20:14 +0200

Hello Dave! The thanks go right back for your initial work.

I wonder why you are still receiving injected mails through the contact form. Ryan's code seems OK to me....

Cool! Thanks for turning my scribblings into something more prac

Dave — Fri, 16 Sep 2005 08:29:30 +0200

Cool! Thanks for turning my scribblings into something more practical. On a side note, there's an updated WP-Contact Form over on ryan duff's site. For some reason, I'm still getting weird emails with injected headers...I am not clever enough to figure out how it's happening...maybe some kind of alternate text encoding is going on.