Browsers have come a long way in preventing malicious scripts from compromising a user’s system, but XSS (Cross Site Scripting) still poses a security threat for developers. In version 3, we make use of a couple libraries packaged with the minPHP framework and recommend you do the same with your plugins, modules, or gateways. They are the Html and Formhelpers.
In the previous article I showed how to eliminate SQL inection, but what do you do when a user submits some XSS code through a web form? Obviously parameter binding won’t help you there, so what do you do? Nothing. Well, at least for now, and here’s why:
- Sanitizing input for XSS is expensive (both computationally, and economically). Web technologies change very frequently. What if W3C decides to add an “ontrippleclick” event?
- Not all form data will end up in an HTML document. Some data is destined for emails or 3rd party APIs.
- Sanitizing may make the data less or unsearchable by the database engine.
So when do we deal with this potentially hazardous data? Why, when we render it of course. And here’s how that’s done:
<div>Name: <?php $this->Html->_($name);?></div>
In the above example, Html::_() both sanitizes and prints the data, but we can force it to return the sanitized output by setting the 2nd parameter to false. Neat-o. When used in a form, the Form helper will take care of drawing the form field and sanitizing the data.
<div>Name: <?php echo $this->Form->fieldText($name);?></div>
One thing to note is that we’re not destroying the XSS, we’re simply treating it as plain-text within an HTML document. While this takes care of most scenarios, there are some instances the Html helper can’t help you with. One such case is in dealing with the href attribute of an anchor tag. As a programmer you simply need to be aware of such pitfalls and address them accordingly.