For most web designers, especially those who work solo, a custom built content management system is still a tall order. Fortunately there are numerous commercial and open source content management systems available, which offer a practical and affordable means of wrangling content. However, a “one size fits all” content management system that doesn’t address a site’s specific content requirements can introduce as many problems as it solves.

One page, one blob

The easier a content management system (CMS) is to configure and use, the more restrictive it is likely to be. HTML and CSS offer a rich toolset for describing and presenting all kinds of content, yet most CMSs cannot be configured to address the myriad types of content a content editor needs to display. Instead, the content editor is given the ability to modify just one “blob” of content per webpage. This format suits the majority of webpages, but assumes that the content editor is happy to have just one block of plain text per page, or that they are comfortable styling text with regular HTML tags, or a ’simplified’ variation such as markdown. For the novice, HTML is hardly child’s play, and trusting a client to write compliant markup is optimistic to say the least. That’s where WYSIWYG (What You See Is What You Get, pronounced “wizzywig”) editors come to the rescue, and that’s when problems start to creep in.

The WYSIWYG problem

The WYSIWYG editor is at the heart of most modern content management systems, if not by design, then because web designers install one themselves. They are used as a “cure all” by CMS developers and web designers alike, because they provide content editors with a powerful interface for styling content, using a toolset that replicates the desktop word processors with which they are already familiar. The two most popular WYSIWG editors are TinyMCE and FCKEditor. Both use Javascript to enhance a regular HTML textarea, and do so via a menu of buttons similar to that found in Microsoft Word. This probably sounds ideal – a website’s content editor can take total ownership of their content, styling it in any way they please. But content editors are precisely that: editors. They are not designers, and shouldn’t have to – or be allowed to – make decisions that affect the design of their content. Sadly, this is exactly the power that WYSIWYG editors put at their fingertips.

Tinymce in all its glory. Watch your client destroy your layout in mere seconds!

Let loose with a WYSIWYG editor a content editor can mix and match font size, face and color, and even add tables, images, background colors, and emoticons to a webpage. If you think they will have the self control to exercise restraint, think again. Even the ability to alter the appearance of text can have disastrous results. I have seen a content editor use a WYSIWG editor to set body copy in 16 point, 12 point, and 10 point at various places on the same page, and in three different typefaces. Another client inexplicably changed the color of list items to exactly the same blue used throughout the site to indicate hyperlinks. The impact such misguided decisions have on usability and design should be obvious.

Of course the blame doesn’t lie with the content editor. They don’t have training as a graphic designer, nor can we expect them to grasp the subtleties of interactive design. The problem is that WYSIWYG editors mix the description of content (headings, lists, blockquotes) with its design (typefaces, colors, and point sizes). Web designers have long understood the importance of separating content from presentation, but WYSIWYG editors snatch that separation away from us.

Dial it back

Fortunately, most WYSIWYG editors allow you to limit their functionality to suit your needs. This can either be done using a CMS’s administration interface, or by editing a configuration file. When faced with a WYSIWYG editor I dial its functionality right back, leaving only the core set of tools needed to effectively describe content. Does a content editor need to specify background colors for text? Of course not. The size of text? Nope. Paragraph alignment? Uh-uh. Tables? Lets not even go there. I don’t even let a content editor underline text. Why? Because underlined text looks like a link.

Headings (h1, h2 etc), bold, italic, ordered lists, unordered lists, blockquotes, and hyperlinks: these should provide sufficient scope to describe most types of content. Let your regular CSS stylesheets style the output, and you’ll ensure the rendered content fits seamlessly with your existing website layout.

The copy and paste problem

WYSIWYG editors present another problem I haven’t touched on yet. Usually a website’s copy isn’t typed directly into a content management system, it is composed in a word processor, then pasted into the CMS. When this happens the formatting of the source text is brought across too, warts and all. Despite your best efforts to limit your client’s ability to style content, with one keystroke they can inadvertently bypass your safeguards. There are two solutions to this problem. The first involves education. Both FCKEditor and TinyMCE include a ‘paste as plain text’ button, that gives users the option of stripping all formatting from text as it is pasted into the WYSIWYG editor. The only problem is that your client needs to remember to use the button. The second option is more pro-active. Both FCKEditor and TinyMCE have a configuration setting that forces content to be pasted as plain text.

What about web standards?

A criticism often leveled at WYSIWYG editors is that they produce spaghetti code. In part, this is true. The only way a WYSIWYG editor can define the color of text, for instance, is by applying an inline style to your markup. But if you limit the WYSIWYG to a few core capabilities, as I suggested above, there is far less that can go wrong. The developers of WSIWYG editors are mindful of the need for standards compliance, and I have found that in most cases it isn’t hard to get both TinyMCE and FCKEditor to generate tidy markup.

Other options

Building a CMS from scratch is a huge task. I ought to know – most of my websites are powered by a CMS I built myself. Unless you are a competent programmer and have a heap of time up your sleeve (or just enjoy a challenge!), building your own CMS isn’t an option I would recommend lightly, but the advantages of the DIY route certainly pay off in the long run.

Building your own CMS gives you absolute control over how the software functions, allowing you to customize it to your own needs with fine grained control. When something breaks, you know how to fix it. If you want to add a new feature to the CMS, you just go ahead and add it, rather than submitting a feature request to the software vendor and crossing your fingers.

Another option to consider is XStandard, a WYSIWYG editor that touts its standards compliance and accessibility features. The big drawback I can see with XStandard is that it requires the content editor to install the XStandard application on their local machine. By contrast, a javascript based WYSIWYG editor makes your website editable from any computer sporting a modern web browser.

Whichever approach you take to content management, so long as you give careful thought to both your client’s needs and the pitfalls of giving them free rein, it is possible to strike a balance that keeps everyone happy. Giving clients the ability to edit their website’s content, and creating beautiful, standards compliant websites needn’t be mutually exclusive goals.

How they do it

An email is composed simply of raw text that is formatted using a standardized syntax. When we add a contact form to a website we allow our visitors to supply data such as their name, email address, subject and message, which we then format and send using PHP’s mail function. For instance:

<?php

  $recipient = 'recipient@mydomain.com';
  $subject = $_POST["subject"];
  $message = $_POST["message"];
  $headers = "From: ".$_POST["email"];
  mail($recipient,$subject,$message,$headers);

?>

will produce the following raw email data:

To: recipient@mydomain.com
Subject: Hello
From: sender@theirdomain.com

Hi, I love your site.

Seems harmless enough, right? We have hard coded the recipient’s email address in PHP, so it would be natural to assume that a visitor couldn’t use our contact form to send an email to anyone except the intended recipient.

Wrong!

Because we include the visitor’s email address in the email header, it is surprisingly simple for a malicious user to insert additional headers in the email field. They can do this in the following manner:

sender@theirdomain.com%0ABcc:recipient@anotherdomain.com

%0A is the hexidecimal representation of a linefeed, and forces a line break in the email’s header block. Now the raw email will look like this:

To: recipient@mydomain.com
Subject: Hello
From: sender@theirdomain.com
Bcc: recipient@anotherdomain.com

Hi, I love your site.

In this basic example the spammer has simply inserted a single additional recipient. In practice they will use more advanced injection techniques to hide your original message and display their own in its place, and will also insert the email addresses of thousands of hapless recipients. Now your form is being used to send spam.

As the hard coded recipient of the form, the website owner (your client) will become aware that something fishy is going on when they begin to receive large amounts of spam, apparently originating from their own site. Shortly your web host will also notice the high volume of spam emails being sent from your client’s domain, and shut the site down. They will send you an irate email requesting that your patch your insecure PHP scripts or find another hosting company. Needless to say, this chain of events is bad for your relationship with both your web host and your client!

The solution

Protecting against header injection attacks is a simple matter of validating user supplied data. Primarily, header injection relies on the attacker being able to include linebreaks in strings that will appear in an email’s header. By testing for the presence of these linebreaks in user-supplied data we can stop the spammer in their tracks. I have written a small function to simplify this process – it accepts as its parameter an array of the header fields we need to test:

<?php

function checkFields($values){
	$injection = false;
	for ($n=0;$n<count($values);$n++){
		if (eregi("%0A",$values[$n]) || eregi("%0D",$values[$n]) || eregi("\\r",$values[$n]) || eregi("\\n",$values[$n])){
			$injection = true;
		}
	}
	return $injection;
}

$from = $_POST['from'];
$email = $_POST['email'];
$result = checkFields(Array($from,$email));
if ($result==true){
	die("Header injection detected!");
}

?>

How to tell if your form is being exploited

To test a form to see if it is vulnerable, a spammer will first try and inject a single bcc header containing a throwaway email address (usually an AOL address). They then check that AOL address to see if they received the test email. If so, they will begin using your form as a spam relay.

The only flaw in this otherwise perfect plan is that the email’s intended recipient (whose email address is hard coded into your PHP form handling script) will also be receiving these probe emails.

So if one of your clients complains they are getting a lot of ’spam’ sent to them via their contact form, sit up and pay attention. There is a chance the ’spam’ they mention is actual a spammer’s probe emails. Ask your client to send you a few examples of the emails they are receiving. A probe will contain text that looks something like this:

said

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: an wan that makes me proud iv ailey f
bcc: onemoreaddress@hotpop.com

934522c25fb7a2507489e97c4043af14

I’m still getting annoying probe emails

Even though your form validation may already be filtering header fields for line breaks, you may still receive a spammer’s probe emails. This is because the spammer – or more precisely their ’spambot’ – is attempting to blindly inject into every form field it finds, including the ‘message’ field (the probe example I gave above was actually the result of a spammer’s attempt to inject into the message field of a client’s contact form). The message field doesn’t pose a security risk since it does not appear in the email’s header, but unless you validate it as well then the form’s intended recipient will continue receiving probe emails. Of course the message field can legitimately contain linebreaks, so you will need to validate it for other telltale strings such as “Bcc:” or “Content-Type:” both of which are common in injection attacks. Make sure your validation ignores case, since an email header is case insensitive.

Conclusion

Validate, validate, validate. And don’t trust your website visitors, not all of them are good guys!

Further reading

Email Injection

For a really detailed description of email header injection in PHP, check out the Secure PHP wiki page on the topic.

Form Post Hijacking

When header injection attacks became widespread a couple of my sites were compromised. I found this article useful in helping me understand the problem.

UPDATE 12 Dec 2006: I realized that I had forgotten to double escape the \ characters in my validation function when I posted this article, so they weren’t showing up. Whoops! I have updated the function accordingly.

The image gallery was controlled by a Javascript which swapped the src parameter of a placeholder img tag each time the user selected a new image.

In my HTML markup I had a basic image tag with an ID applied to it:

<img id="placeholderimage" alt="" />

When the user selected a new image (by clicking ‘next’ or ‘prev’ in my image gallery navigation), a javascript was triggered to load a jpeg into the placeholder:

document.getElementById('placeholderimage').src = "mynewpic.jpg";

The problem with this method is that while the new image loads into the placeholder, the old image remains on the page. To the user it appears as if nothing is happening. The solution is to hide the image while it loads, and show the user some sort of load indicator while they wait. When the image has completed loading, reveal it again and hide the load indicator.

The specifics of hiding/revealing the load indicator are beyond the scope of this article, so I won’t bore you with them here. Instead I’ll demonstrate the method by which I hid and revealed the image, as that is what caused problems in Safari.

To hide the image, I used javascript to apply the CSS style display:none before loading the new jpeg. I also created an onload event handler for my image, to detect when it had finished loading. Inside my onload function I revealed the image again:

document.getElementById('placeholderimage').onload=function(){
        document.getElementById('placeholderimage').style.display = "block";
};
document.getElementById('placeholderimage').style.display = "none";
document.getElementById('placeholderimage').src = "mynewpic.jpg";

Easy peasy. The image is removed from the document flow when it starts to load, and returned when it finishes.

Everything seemed to be rocking nicely, until I fired up the site Safari 1.2. The image was hiding as expected, but my onload function was never evoked. After some head scratching I traced the problem to my use of display:block when hiding the image. I think Safari’s logic is that because the image is no longer part of the document flow, there is no point bothering to load it. Unlike other browsers, Safari never initiated the image load, and that’s why the onload never fired.

Armed with this new knowledge, we have a couple of “Safari friendly” options at our displosal:

• Use visibility not display

  If we use visibility = "hidden"; instead of display = "none"; to hide the image, everything works fine. The problem with using visibility is that the image is not removed from the document flow, meaning a gap is left on the page where the image used to be. Depending on the layout of your image gallery that may not be an issue for you – it may in fact be desirable. If it is an issue, you can set the height of the image (or it’s containing element if there is one) to zero, then use the onload handler to reset it to it’s correct height. Fiddly, but it works.

• Move the image outside the viewport

  If your image has the CSS property position:absolute, then you should be able to move it off screen by setting either it’s top or left property to a suitable low value, for example: left: -1000em; That ought to place the image off screen out of sight.

There may be other alternatives, and you can choose the one that suits you best. The important thing to remember is don’t use display:block to hide images while you swap their image source, or risk the wrath of Safari users!

For anyone interested to see the final implementation of my image gallery, here it is.

Coming from a Flash background, where upgrades to the authoring program, programming language and player are frequent, I wonder whether PHP might have something to learn from Flash.

The Flash Player is backwards compatible with old Flash content. Flash Player 8 will play content published in Flash 6 format, even though the two have a vastly different programming language (Actionscript 1.0, and Actionscript 2.0). This can be achieved because a Flash swf contains metadata identifying its minor and major version. As soon as the Flash Player opens a swf file, it can check to see what version of Flash player it has been published for, and treat the swf accordingly.

Why can’t a PHP file have similar metadata? For instance, a PHP file might begin:

<?php4

Identifying to the rendering engine to treat the file as PHP4. If a version identifier wasn’t present, it would treat the file as belonging to the latest version.

OK, so I admit I know next to nothing about the inner workings of PHP, and the solution I’ve outlined may be totally impossible to implment. But you can’t blame a frustrated user for taking a stab!