Red flag induced heart attack averted ;). Primarily I was just concerned that you might be following some of the excellent (not) advice out there: http://www.zfforums.com/zend-framework-components-13/databases-20/stripslashes-zend_db_table_row-object-2128.html
I've actually seen this in real life - I almost did have a heart attack then ;). Note to self - kick someone into setting a limit on View escape settings... >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. Sounds like a bug somewhere. If the database adapter were working correctly, input would be escaped going in and unescaped coming out without any other external steps needed. I'd say to copy this to the DB mailing list and give as much detail as possible about your setup, i.e. DBMS, adapter used, character encoding of DB (can check via phpmyadmin or its equivalent), settings/options passed to adapter, etc. I'd also verify this is occurring. A reproducible script goes a long way ;). Particularly, check if it's consistent everywhere. There can be cases where input is massaged by other factors (jQuery can add slashes when submitting data, for example, depending on how things flow). A reproducible script would also eliminate these and any other potential side effects making the problem a bit narrowed in scope and hopefully therefore simpler to figure out. Paddy P.S. Sorry for the overkill reply last time around :P. 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: Sat, February 20, 2010 9:04:26 AM Subject: Re: [fw-general] Escape, stripslashes and html entities 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
