ZF-8715: Inconsistent encoding across several view helpers

Issue Type: Bug Created: 2010-01-05T13:16:13.000+0000 Last Updated: 2010-02-18T06:14:37.000+0000 Status: Resolved Fix version(s): - 1.9.7 (11/Jan/10)

Reporter: Matthew Weier O'Phinney (matthew) Assignee: Matthew Weier O'Phinney (matthew) Tags: - Zend_Dojo

  • Zend_Feed
  • Zend_Form
  • Zend_Log
  • Zend_Service_Twitter
  • Zend_Tag
  • Zend_View

Related issues: - ZF-9205



Zend_Dojo's _renderLayers() method includes a call to htmlentities(). Unfortunately, it does not pull the encoding from the view object, which means it will only work on ASCII characters, which can potentially open multibyte XSS vectors.

Zend_View_Helper_Placeholder_Container, line 29, hardcodes the encoding (instead of using the view object's), and should likely use htmlspecialchars() instead.

Zend_Form_Decorator_HtmlTag, Zend_Service_Twitter, Zend_Feed_Element, and Zend_View_Helper_Navigation_Sitemap hardcode htmlspecialchars() calls to use UTF-8.

Zend_Log_Formatter_Xml, Zend_Tag_Cloud_Decorator_HtmlTag, Zend_Tag_Cloud_Decorator_HtmlCloud, and Zend_View_Helper_HeadStyle do not pass encoding information at all.

Zend_Filter_HtmlEntities defaults to ISO-8859-1, but should default to UTF-8 (same applies to Zend_View). Additionally, for consistency, it should implement a setEncoding() method that proxies to setCharset() (or vice-versa).

Basically, all instances of htmlentities() and/or htmlspecialchars() should use the encoding argument (3rd parameter), defaulting to UTF-8 if no encoding is known.


Posted by Matthew Weier O'Phinney (matthew) on 2010-01-06T12:36:24.000+0000

Updated subject and description to be comprehensive of all reported components.

Posted by Matthew Weier O'Phinney (matthew) on 2010-01-06T12:39:50.000+0000

Actually, Zend_View_Helper_Placeholder_Container_Standalone does use the view by default; only in the absence of a view object does it call htmlentities with a hard-coded encoding. I think in this case, it fits fine.

Posted by Matthew Weier O'Phinney (matthew) on 2010-01-06T12:48:37.000+0000

Zend_Service_Twitter hardcodes the encoding due to expectations of the Twitter API, and, as such, is correct in the current implementation.

Posted by Matthew Weier O'Phinney (matthew) on 2010-01-06T13:28:43.000+0000

All code updated in both trunk and 1.9 release branch.

Posted by Matthew Weier O'Phinney (matthew) on 2010-01-06T13:29:23.000+0000

Added Zend_Form to list of components affected

Posted by Thomas Weidner (thomas) on 2010-01-06T14:17:43.000+0000

Hint: r20104 could be seen as BC break for Zend_Filter_HtmlEntities.

Problematic changes: 1.) Encoding defaults changed 2.) Protected members changed

This could lead to problems with existing classes extending this filter. Therefor a migration note should be added to the 1.10 migration chapter.

Posted by Thomas Weidner (thomas) on 2010-01-06T14:20:06.000+0000

As the change has also be backported to 1.9 series the migration note should be added to the 1.9 migration chapter.

Posted by Matthew Weier O'Phinney (matthew) on 2010-01-06T14:36:34.000+0000

The encoding issues are security related, so as such, necessary. The changes from CharSet to Encoding are more consistency, however -- but it made sense to deal with those at the same time.

I'll update the migration chapter in the morning prior to packaging the release.

As for the protected member changes, the change should be transparent due to how the setters were written and the use of the new accessors for retrieving the values (instead of using the protected members directly); it's unlikely developers are overriding the setters/accessors in most cases anyways. I'll still make a note, however.

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.