BlogMKE

Most of us have been in the situation where you spend a good chunk of time writing a form for a client – adding fields, handling every miniscule conditional client request (”Can these three checkboxes only appear every third vernal equinox, after 0500hrs, and can they have a baby blue background? Thanks!”), cleaning and validating the data to within an inch of its life – only to get an email (sometimes within mere hours of making the form live) that goes something like this:

Dear web person:
Why have I gotten four emails from 7622uhdxx@gmail.com concerning time share opportunities in the Ozarks in the past hour?

Oh noes, you’ve got form spam.

“But I’m using both client and server-side validation!”, you cry. Yes, I’ve said the same thing to myself in these situations. Now, unless your particular form is a valuable target, like, say, I don’t know, one of the forms associated with the Facebook account creation process, you’re probably not dealing with an actual human being hitting your goods. No, the galley slaves of the 21st century probably have bigger captchas to fry than your little feedback form.

So, usually it’s safe to assume that you’re getting hit with a script – a script that’s learned a few things over the years. The first thing it probably learned was to ignore Javascript, so all the “return false” statements in the world aren’t going to save you. Well, what about server-side validation? Unfortunately, this script knows about required fields, and just to be on the safe side, it puts something in every input area you’ve got. Lastly, it knows what an email address looks like and knows how to populate the field labeled (conveniently) “Email” with one that passes your average regular expression.

It’s not looking good for our intrepid little form.

Sometimes, though, you can use a script’s own intelligence against itself. This is where all this canary nonsense comes in. A canary trap is a way to identify where a leak of sensitive information is coming from. If you create six versions of a classified memo, each one with an identifying characteristic, knowing where an information leak is coming from is would then be a matter of simply paying attention to which version of the information was leaked, and to whom that version was given.

Sort of similarly, a script isn’t going to read CSS. It doesn’t need to, as it’s not all that concerned with the elegance of your design. As mentioned before, it is kind of a brute, so it’s going to put data in every field, even in one that’s been hidden with CSS. So, the basic idea is that if your own form validation receives data from a field that a normal (non-script) user wouldn’t even be seeing, then you know something isn’t right. Knowing that, you can just kill the submission action and get on with your day.

So, add an input area to an HTML form and then hide it with CSS:

<span style="display:none;"><input type="text" name="canary"></input></span>

It probably doesn’t have to be inline CSS. Feel free to simply add the rule to your stylesheet.

And then use your language of choice for some server-side validation to catch whether or not something’s been put in your canary field.

<?php
if ($_POST['canary']) {
die('Oh no you didn\'t!');
}
?>

Obviously, you can call the input anything you want . . . like, Melvin. Call it Melvin. This method has worked pretty well for me so far. One does have to consider how this would affect legitimate users of screen readers, or people who, for whatever reason, aren’t seeing CSS. I think it’s a matter of graceful degradation. It’s not a required field, and a real person who actually encounters it is probably most likely to leave it blank anyway. It is more likely than not that this would not be an impediment to these legitimate users.