Tag Archives: spam

Protecting wp-contact-form from spam

Ever since I installed WordPress on my (virtual) server, I’ve been using the WP Contact Form plugin to provide me with simple contact form. The plugin isn’t exactly under active development (Last Updated: 2009-8-28), but it got the job done and I was quite happy with it. Until spammers found the page and started abusing it, that is. There’s a bunch of other Contactform-plugins in the wordpress.org plugins repository, but most of them were either too feature-packed or development for them seemed to have stopped.

I considered adding ReCaptcha at first, but why would I want to put my visitors through such an ordeal; the captcha’s seem to have gotten very difficult to decipher.  Next possibility; implement Akismet (Mollom would have been a great choice as well)? There’s a great Akismet PHP5-class, you just provide your API-key and off you go. But it seemed kind of inefficient to have to do all that with the official Akismet-plugin already in place?

But wait a minute, why not just piggyback on the Akismet-plugin, as the Clean-contact plugin and wp-contactform-akismet did? Keep it simple stupid and so I just copy/pasted the clean_contact_akismet-function from Clean Contact’s code into my wp-content/plugins/wp-contact-form/wp-contactform.php and on line 142 I changed:

mail($recipient, $subject, $fullmsg, $headers);
$results = '<div style="font-weight: bold;">' . $success_msg . '</div>';
echo $results;


if (!$akismet) {
mail($recipient, $subject, $fullmsg, $headers);
$results = $success_msg;
} else {
$results = 'If it looks like spam and smells like spam, it must be spam. Leave (or rephrase)!';
echo '<div style="font-weight: bold;">'.$results.'</div>';

That was all it took to add Akismet spam-filtering to that KISS-y wp-contact-form plugin. I wonder why this isn’t in the plugin already?

WebApp Security is mandatory (even for spammy virals)

I just received a mail from Frank Goossens. I’ve apparently invited myself to view “an adorable Christmas-card” containing “warm wishes”. Moreover I tried to guilt-trick myself into forwarding that same card to friends and family, as that simple gesture would provide the poor with (unhealthy fried) food for the Poverello Christmas-dinner.

In general I don’t like virals, but I was curious to find out if Agency.com just spammed me or if someone (ab)used my name and email to bug me. So I clicked the link, told Noscript to trust the (flash-)site temporarily, looked at the Firebug-output while testing the application and tinkering with some of its URL’s.

The results:

  • One can tweak the system for the “message” to contain links and images (lesson 1: do not solely rely on client-side validation in flash or javascript)
  • Going one step further, you can also insert javascript in that message. That code isn’t  executed inside the flash e-card, but assuming there is a plain html-backend (there always is, for reporting or export-purposes) it’s trivial to sniff the backend URL and steal the session-cookie as soon as someone accesses a page which contains that message. The URL and session-cookie can be used to gain access to the admin-site (lesson 2: render all user-submitted data harmless before storing in the database, use a html filtering component if need be)
  • It’s trivial to abuse this system to send spam with 1 automated GET-request per 5 recipients (lesson 3: think about how your system can be abused an try to harden it accordingly)
  • It’s really easy to  “harvest” all 48.000 names, e-mail-adresses and messages sent (lesson 4: auto-numbers are a bitch)

Ladies and Gentleman marketeers and ad-agency account executives; do not think that virals, mini-sites and e-cards aren’t susceptible to hackers. You should consider web application security as a mandatory feature! Unless you have an unstoppable urge to gift-wrap your (or worse, your customers) data and hand it out to spammers and hackers, off course.