On Saturday 20 Feb 2010 03:35:23 Pádraic Brady wrote: > 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.
Yes, that's what I'm doing :) The words were written down to say in short the default escape functions in Zend_View aren't sufficient to remove slashes. Of course not using htmlspecialchars() can cause XSS and I'm very aware of that fact :) > 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. My magic quotes are off, that's for sure. My problem is I never add slashes or do mysql_real_escape_string() (alike) functions by hand. I just pass the data to Zend_Db and the result is escaped by Zend_Db. If I look into my db, there's only one slash added to a certain quote character. If you fetch the data from the db the string isn't removed, and after your and Hector's reply I'm sure that should be done by the system itself. I need to look into the Zend_Db code to find out when and why escaping is turned off I assume. > 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 I saw the ZF2 proposal and that's why I thought about this. If I can fix this issue without the modification of Zend_View it's of course a much better method. Regards, Jurian -- Jurian Sluiman CTO Soflomo V.O.F. http://soflomo.com
