Note that there are some explanatory texts on larger screens.

plurals
  1. POBest practice for HTML escaping user-supplied data with PHP (and ZF)
    primarykey
    data
    text
    <p><em>Note: I'm using Zend Framework, but I think most of this applies to PHP coding in general.</em></p> <p>I'm trying to choose a strategy for writing views scripts, possibly with the help of a templating engine. Motivations: <strong>clarity and security</strong>. I'm just not happy with writing .phtml scripts. This syntax is awfully verbose to do the most often needed thing - outputting a variable:</p> <pre><code>&lt;?php echo $this-&gt;escape($this-&gt;myVariable); ?&gt; </code></pre> <p>In addition to the code being lengthy, IMHO the template author shouldn't have to remember (and bother) writing an escape call each time he/she wants to output a variable. Forgetting the call will almost definitely result in an XSS vulnerability.</p> <p>I have two possible solutions for this problem:</p> <p><strong>Solution 1: A template engine with automatic escaping</strong></p> <p>I think at least <a href="http://smarty.net" rel="nofollow noreferrer">Smarty</a> has an option for automatically escaping html entities when outputting variables. There are <a href="http://nosmarty.net" rel="nofollow noreferrer">points against Smarty</a>, but maybe at least some of them are addressed in the upcoming 3.0 - I haven't checked yet.</p> <p>XML based template engines like <a href="http://phptal.org" rel="nofollow noreferrer">PHPTAL</a> will also escape any data by default. They might look quite odd for a beginner, though. Maybe still worth trying?</p> <p><strong>Solution 2: Escape the data in the Model</strong></p> <p>Of course, the other option would be to escape the needed data already in the Model (or even the controller?). The Model should already know the content-type (mainly plain text or HTML text) of each field, so it would be kind of logical to escape the data there. The view could consider all data as safe HTML. This would allow eg. changing the datatype of a field from plain text to HTML without touching the view script - only by changing the Model.</p> <p>But then again, it doesn't feel like good MVC practice. In addition, there are problems with this approach as well:</p> <ul> <li>sometimes the view only wants to print the first n characters, and we don't want to end up truncating the data <code>foo &amp; bar</code> as <code>foo &amp;am</code> (having first escaped it as <code>foo &amp;amp; bar</code>)</li> <li>maybe the view wants to construct an URL with varName=$varName in the querystring - again, escaping already in the Model would be bad. </li> </ul> <p>(These problems could be addressed by providing two versions of the data, or unescaping in the template. Seems bad to me.)</p> <p>Ideas? Am I missing something? What do you consider "the best practice"?</p> <p>PS. This post is about finding a general solution for any user-supplied plain-text data that may contain <code>&lt;</code> or <code>&gt;</code> or any other characters. So, filtering data before saving it to the database isn't the solution.</p> <p><strong>Update:</strong></p> <p>Thanks for all comments so far. I did some more research and will next evaluate <a href="http://www.twig-project.org/" rel="nofollow noreferrer">Twig</a> and possibly <a href="http://www.invenzzia.org/en/projects/open-power-libraries/open-power-template" rel="nofollow noreferrer">Open Power Template</a>. Both seem interesting: Twig looks very straightforward, but the project is young. On the XML side, OPT's syntax looks a bit nicer than PHPTAL's. Both Twig and OPT are quite well documented.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload