Published 2005-04-04 00:00:00

Whenever someone starts saying template engines, there's an equally vocal community that gently suggests that PHP is a great template engine. Well, I think this week that sounded alot like bollocks...

The pear website, while not a masterpiece for PHP code, has however been written by some pretty smart people, and uses (in parts) the concept of PHP as a template engine. Last week however we got a very polite email to the group mentioning that it was possible to do Cross site scripting attacks on some pages.

The root of the issue was that it was outputing variables (either directly from input or indirectly) which had not been escaped correctly for HTML or javascript, so it was possible to make your favourite javascript hacks work through the url..

While the issues with pearweb where not that serious, it did illustrate the problem of simple PHP templating against more complex engines like Flexy.

When I wrote Flexy, I'd been doing webdev for quite a while, and realized that like everyone else, I make mistakes (some may say like my opinions on this blog). So to some degree, I tend to prefer my applications to protect me from myself, while at the same time allow me to deliberatly break things.

One of the more unusual features of Flexy, is that all tags eg. {stuffThatOutputsVariables} or the method calls are by default html escaped. (unless you explicitly add the :h modifier). Not only this, these tags within javascript blocks, just dont work. You are forced to use the <flexy:tojavascript tags to send variables to the javascript code, again, reducing the chances of accidentally letting your friendly hacker have fun with your site..

So while PHP templates have some advantages, in that it lacks the requirement for compiling. That penalty seems a small price to pay for the extra protection.. so Flexy's new catchphrase may be, "Put your condom on, and use a Flexy Template Engine..."

Mentioned By:
phparch.com : php | architect - The PHP Magazine for PHP Professionals (181 referals)
google.com : april (156 referals)
google.com : flexy template (117 referals)
www.php-mag.net : &nbsp;International PHP Magazine - Cutting-Edge Technologies for Web Professionals (114 referals)
www.nexen.net : Nexen.net : Portail francais PHP et MySQL (83 referals)
www.phpdeveloper.org : PHPDeveloper.org: PHP News, Views, and Community... (61 referals)
google.com : php template engine (51 referals)
google.com : flexy template engine (49 referals)
entwickler.com : entwickler.com (44 referals)
www.planet-php.net : Planet PHP (43 referals)
netoffice.sourceforge.net : NetOffice - Forums (41 referals)
www.nexen.net : Nexen.net: Portail PHP et MySQL - PHP comme moteur de template : un dsastre? (37 referals)
php.openstates.org : Best Practices PHP 5 (36 referals)
google.com : flexy templates (33 referals)
www.mikenaberezny.com : MikeNaberezny.com &raquo; Symfony Templates and Ruby&#8217;s ERb (29 referals)
google.com : PHP templating (25 referals)
www.mikenaberezny.com : Mike Naberezny - Symfony Templates and Ruby&#8217;s ERb (24 referals)
google.com : php template (21 referals)
blog.html.it : Template Engine | &lt;edit&gt; - Il blog di HTML.it (21 referals)
google.com : december (20 referals)

Comments

Not really template engine related
Well this is a good security feature of flexy i don't really see how it works into template engine vs php debate.

First i haven't heard of any other template engine doing what flexy does. And second there is nothing to stop you from adding this same security call to php only templates if your using some kind of controlling class like Savant.

I do think it says its not good to just roll your own simple template setup since there are lots of things you'll forget to do.
#0 - Joshua Eichorn ( Link) on 2005-04-05 00:50:17 Delete Comment
Ouput Filtering, Not Templates
This seems more a problem of (as Shiflett might say) "failure to escape output." Eichorn is right: this is not a point for or against template systems per se, but about proper programming practice.

With that in mind, a template system can help enforce automatic escaping of output (or at least make it convenient). But technically, you don't need Flexy or Smarty or even Savant to do that; write a quickie function to apply htmlspecialchars (or whatever) to the variable, and use that in place of "echo" or "print" (or echo that function instead of the variable).

And now the shameless self-promotion: Savant3 supports this via its "scrub" plugin, which lets you define default and custom scrubbers for output; the other plugins in Savant3 (e.g. the "form" plugins) call scrub() on all output automatically.


Savant can be found at http://phpsavant.com.
#1 - Paul M. Jones ( Link) on 2005-04-05 01:42:39 Delete Comment
I Agree
I agree that output filtering is a strong reason to use a template engine.

WACT has automatic output filtering as well. All output values are escaped unless you use the raw designation to override it. The raw designation is special and must be last in any series of filters to operate correctly. The 'html' filter performs output escaping appropriate for an html document and is the default.

{$value} // filtered
{$value|raw} // unfiltered
{$value|capitalize|raw} // unfiltered
{$value|raw|capitalize} // filtered
{$value|html} // filtered
{$value|html|capitalize} // error - double filtered
{$value|html|capitalize|raw} // filtered
#2 - Jeff Moore ( Link) on 2005-04-05 03:26:45 Delete Comment
not escaping values? That's hardly a template issue
Honestly, the code for pearweb is a horrible example. Using $_* variables directly in a template or in code without any processing is just, well, not intelligent.

Sure it's great to protect you from yourself, but better is to approach design from the standpoint of a hacker

"How can I use this code to gain access to a machine/spread my virus or malicious code/do DoS attacks?"

It doesn't really matter how fancy your template engine is, honestly, as benchmarking should show that only the highest traffic sites will be slowed down by the template engine.

Far more important are considerations such as:

1) Do I have to make a directory world-writeable for my compiled template engine, and if so, is there any way a malicious user can upload their own scripts to replace mine?

2) How slow is my database access in the backend?

3) Should I be using a cache?

To claim PHP as a template language is somehow more vulnerable to attack than any compiling engine doesn't make sense. To be truly secure, you still have to do lots of non-intuitive work (compile the templates at home and upload the compiled copies).
#3 - Greg Beaver ( Link) on 2005-04-05 23:08:21 Delete Comment
PHP Website Development at India
Great resource and list, will certainly be bookmarking this page.I’m glad everyone is finding this useful,Thank For Post....
#4 - Teamads ( Link) on 2009-10-03 19:11:29 Delete Comment

Add Your Comment

Follow us on