Zend Framework updates fix security vulnerabilities

Three versions of the Zend Framework, 1.9.7, 1.8.5, and 1.7.9, have been released. In addition to over 40 bugfixes between them, these three releases are the first releases resolve six security vulnerabilities reported against Zend Framework in recent weeks. The following security vulnerabilities are resolved in these releases:

Potential XSS or HTML Injection vector in Zend_Json
Zend_Json_Encoder was not taking into account the solidus character (“/”) during encoding, leading to incompatibilities with the JSON specification, and opening the potential for XSS or HTML injection attacks when returning HTML within a JSON string.

Potential XSS vector in Zend_Service_ReCaptcha_MailHide
Zend_Service_ReCaptcha_MailHide had a potential XSS vulnerability. Due to the fact that the email address was never validated, and because its use of htmlentities() did not include the encoding argument, it was potentially possible for a malicious user aware of the issue to inject a specially crafted multibyte string as an attack via the CAPTCHA’s email argument.

Potential MIME-type Injection in Zend_File_Transfer
Zend_File_Transfer had a potential MIME type injection vulnerability for file uploads. In certain situations where either PHP’s ext/finfo extension is not installed and the mime_content_type() function was not available on a system, Zend_File_Transfer would use the user provided value for the type embedded inside the $_FILES superglobal. Additionally, in cases where the functionality was available, but where a type could not be determined by one of them, Zend_File_Transfer would also fallback on the user provided type. Using user provided information for a file’s MIME type in uploads is considered an insecure practice, as it provides attack vectors by malicious users.

Potential XSS vector in Zend_Filter_StripTags when comments allowed
Zend_Filter_StripTags contained an optional setting to allow whitelisting HTML comments in filtered text. Microsoft Internet Explorer and several other browsers allow developers to create conditional functionality via HTML comments, including execution of script events and rendering of additional commented markup. By allowing whitelisting of HTML comments, a malicious user could potentially include XSS exploits within HTML comments that would then be rendered in the final output.

Potential XSS vector in Zend_Dojo_View_Helper_Editor
Zend_Dojo_View_Helper_Editor was incorrectly decorating a TEXTAREA instead of a DIV. The Dojo team has reported that this has security implications as the rich text editor they use is unable to escape content for a TEXTAREA.

Potential XSS vectors due to inconsistent encodings
A number of classes, primarily within the Zend_Form, Zend_Filter, Zend_Form, Zend_Log and Zend_View components, contained character encoding inconsistencies whereby calls to the htmlspecialchars() and htmlentities() functions used undefined or hard coded charset parameters. In many of these cases developers were unable to set a character encoding of their choice. These inconsistencies could, in specific circumstances, allow certain multibyte representations of special HTML characters pass through unescaped leaving applications potentially vulnerable to cross-site scripting (XSS) exploits. Such exploits would only be possible if a developer used a non-typical character encoding (such as UTF-7), allowed users to define the character encoding, or served HTML documents without a valid character set defined.