About Me

PBX I'm Paul Bissex. I build web applications using open source software, especially Django. Started my career doing graphic design for newspapers and magazines in the '90s. Then wrote tech commentary and reviews for Wired, Salon, Chicago Tribune, and others you never heard of. Then I built operations software at a photography school. Then I helped big media serve 40 million pages a day. Then I worked on a translation services API doing millions of dollars of business. Now I'm building the core platform of a global startup accelerator. Feel free to email me.

Book

I co-wrote "Python Web Development with Django". It was the first book to cover the long-awaited Django 1.0. Published by Addison-Wesley and still in print!

Colophon

Built using Django, served with gunicorn and nginx. The database is SQLite. Hosted on a FreeBSD VPS at Johncompanies.com. Comment-spam protection by Akismet.

Elsewhere

Pile o'Tags

Stuff I Use

Bitbucket, Debian Linux, Django, Emacs, FreeBSD, Git, jQuery, LaunchBar, macOS, Markdown, Mercurial, Python, S3, SQLite, Sublime Text, xmonad

Spam Report

At least 236732 pieces of comment spam killed since 2008, mostly via Akismet.

Form hijacking

Does your website contain mail forms that aren't sanitizing input as aggressively as they should? There seems to have been a recent surge in automated (or semi-automated, it's hard to tell) probes and exploits of form mail scripts, all revolving around injecting headers into sent mail.

Here's how it works: Let's say you have a form that allows the user to enter their email address. The black hat's exploit script submits a value for that field that includes a newline, followed by whatever email headers they want to insert: Bcc, for example, or even full-blown MIME-encoded parts.

This is especially a problem in PHP because what's commonly thought of as the "From" parameter to the mail() function is actually an "additional headers" parameter. It accepts a single string containing an arbitrary number of headers separated by newlines -- which the spammers are happy to provide.

The defense is very basic input scrubbing (or bulletproof validation of From addresses) that you'd think would already be in place everywhere, but I was surprised to find several forms on my various sites that were vulnerable to this -- in some cases forms that had been online for several years with zero abuse.

Rather than cast about for the perfect email address validator, I changed the form processing scripts to strip newlines from user input. That's enough to prevent hijacking, but not enough to prevent incredible annoyance, since some forms were being probed dozens of times a day, filling up my spambox with garbled mail. So I added a second check that simply rejects any submission if the string "MIME-Version" is in any of the submitted fields. Crude but effective.

Damon Kohler's "Secure PHP" site has a more detailed explanation of this type of exploit.

Tuesday, November 15th, 2005
php + risks + spam + tips
1 comment

Some related posts: Protecting the server with mod_evasive • Library of 1000 scammy spams • Spam, del.icio.us spam • I filled up my GMail box • Comcast's blacklist • Akismet anti-comment-spam • Trac spam • More quick-not-dirty PHP • RapidWeaver spamming vulnerability • Quick, but not dirty, PHP

• Comment from web design blog , 2 years later

They like to inject forms and enter tons of characters in attempts to break the page. You can add filters, and even things like mod_security for enhanced protection. However, I am still looking for a way to be able to monitor this kind of thing on the server level.

Comments are closed for this post. But I welcome questions/comments via email or Twitter.

Search

Feeds

RSS feed

Atom feed

Older Posts

Complete archive

E-Scribe : a programmer’s blog