>I try to figure out what the best option is to escape my data. I have an UTF-8 >website so actually it's fine to work with the original characters (and no need for htmlentities() or >htmlspecialchars()).
I'm going to assume you just worded that badly because otherwise there are red flags exploding in my head. To clarify (if even needed), there are three strategies for escaping output. Strategy 1 is no escaping. This WILL result in XSS vulnerabilities. Strategy 2 is htmlspecialchars(). This escapes characters potentially interpreted as HTML (e.g. angle brackets, ampersands, etc.). If left intact these are what can be manipulated via input tampering to create XSS exploits (and we just got over fixing misuses of this across the framework in the last 1.9 release). Strategy 3 is htmlentities(). This should be used sparingly, and is typical of English oriented output (non-UTF8) in order to enable display of characters not supported by the current character set encoding. For example the UTF-8 á character can be including in non-UTF8 text by encoding it as the entity á. Since you state your output (and presumably this carries back to input and persistence encoding) is UTF-8 the ONLY valid escaping mechanism is htmlspecialchars(). The function call MUST include the correct encoding as a parameter. htmlentities() on UTF-8 is overkill since UTF-8 natively supports almost any imaginable character without needing entities. >Nevertheless all my data comes from a database and the data is inserted with all quotes escaped. That means by display the texts I need for every variable a >stripslashes(). It sounds a lot like double escaping, e.g. calling addslashes() before data is sent to a database adapter for writing. Can also happen if input is auto-slashed, e.g. magic quotes. This should be disabled/reversed before the database write - most adapters can natively escape correctly. PDO has prepared statements but manually even mysql(i) has its mysql(i)_real_escape_string functions. Slashes via a PHP procedure are never sufficient for database escaping - so I would recommend checking how this is occurring because frankly it's a major red flag for potential SQL Injection vulnerabilities if proper escaping is not being employed. >Stripslashes() everywhere is very ugly and gives cluttered code in all my view scripts. What's the best option to strip the slashes automatically? Replace the escape function by >stripslashes() replaces the problem by another: $this->escape() everywhere instead of stripslashes(). Is it better to escape the variables automatically by overriding the __set() >from Zend_View_Abstract? Another (fail prove) systems to have a smart system to escape my data? Almost impossible to avoid with ZF - 2.0 will carry a method for automatically escaping output variables, but it's a tricky proposition to implement. If you can ascertain the double escaping is innocent in nature, you could work up a replacement setter for Zend_View which accepts a context parameter. Still not pretty, but would force the repetitive stripslashes back to the controllers (or Model accessing helpers) instead of contaminating the View. Remember, valid un-slashed data should not be subject to stripslashes(), so adding it to Zend_View is more difficult than it appears at first glance. Paddy Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative ________________________________ From: Jurian Sluiman <[email protected]> To: [email protected] Sent: Fri, February 19, 2010 10:33:06 PM Subject: [fw-general] Escape, stripslashes and html entities Hi all, I try to figure out what the best option is to escape my data. I have an UTF-8 website so actually it's fine to work with the original characters (and no need for htmlentities() or htmlspecialchars()). Nevertheless all my data comes from a database and the data is inserted with all quotes escaped. That means by display the texts I need for every variable a stripslashes(). Stripslashes() everywhere is very ugly and gives cluttered code in all my view scripts. What's the best option to strip the slashes automatically? Replace the escape function by stripslashes() replaces the problem by another: $this->escape() everywhere instead of stripslashes(). Is it better to escape the variables automatically by overriding the __set() from Zend_View_Abstract? Another (fail prove) systems to have a smart system to escape my data? Thanks in advance, Jurian
