|
|
@@ -343,75 +343,80 @@ $container = new Zend_Navigation(array(
|
|
|
]]></programlisting>
|
|
|
</sect2>
|
|
|
|
|
|
- <para>
|
|
|
- Additionally, users of the 1.9 series may be affected by other changes starting in version
|
|
|
- 1.9.7. These are all security fixes that also have potential backwards compatibility
|
|
|
- implications.
|
|
|
- </para>
|
|
|
-
|
|
|
- <sect2 id="migration.19.zend.dojo.editor">
|
|
|
- <title>Zend_Dojo_View_Helper_Editor</title>
|
|
|
+ <sect2 id="migration.19.security">
|
|
|
+ <title>Security fixes as with 1.9.7</title>
|
|
|
|
|
|
<para>
|
|
|
- A slight change was made in the 1.9 series to modify the default usage of the Editor
|
|
|
- dijit to use <acronym>div</acronym> tags instead of a <acronym>textarea</acronym> tag;
|
|
|
- the latter usage has <ulink
|
|
|
- url="http://api.dojotoolkit.org/jsdoc/HEAD/dijit._editor.RichText">security
|
|
|
- implications</ulink>, and usage of <acronym>div</acronym> tags is recommended by the
|
|
|
- Dojo project.
|
|
|
+ Additionally, users of the 1.9 series may be affected by other changes starting in
|
|
|
+ version 1.9.7. These are all security fixes that also have potential backwards
|
|
|
+ compatibility implications.
|
|
|
</para>
|
|
|
|
|
|
- <para>
|
|
|
- In order to still allow graceful degradation, a new <varname>degrade</varname> option
|
|
|
- was added to the view helper; this would allow developers to optionally use a
|
|
|
- <acronym>textarea</acronym> instead. However, this opens applications developed with
|
|
|
- that usage to <acronym>XSS</acronym> vectors. In 1.9.7, we have removed this option.
|
|
|
- Graceful degradation is still supported, however, via a <acronym>noscript</acronym> tag
|
|
|
- that embeds a <acronym>textarea</acronym>. This solution addressess all security
|
|
|
- concerns.
|
|
|
- </para>
|
|
|
+ <sect3 id="migration.19.security.zend.dojo.editor">
|
|
|
+ <title>Zend_Dojo_View_Helper_Editor</title>
|
|
|
|
|
|
- <para>
|
|
|
- The takeaway is that if you were using the <varname>degrade</varname> flag, it will
|
|
|
- simply be ignored at this time.
|
|
|
- </para>
|
|
|
- </sect2>
|
|
|
+ <para>
|
|
|
+ A slight change was made in the 1.9 series to modify the default usage of the Editor
|
|
|
+ dijit to use <acronym>div</acronym> tags instead of a <acronym>textarea</acronym>
|
|
|
+ tag; the latter usage has <ulink
|
|
|
+ url="http://api.dojotoolkit.org/jsdoc/HEAD/dijit._editor.RichText">security
|
|
|
+ implications</ulink>, and usage of <acronym>div</acronym> tags is recommended by the
|
|
|
+ Dojo project.
|
|
|
+ </para>
|
|
|
|
|
|
- <sect2 id="migration.19.zend.filter.html-entities">
|
|
|
- <title>Zend_Filter_HtmlEntities</title>
|
|
|
+ <para>
|
|
|
+ In order to still allow graceful degradation, a new <varname>degrade</varname>
|
|
|
+ option was added to the view helper; this would allow developers to optionally use a
|
|
|
+ <acronym>textarea</acronym> instead. However, this opens applications developed with
|
|
|
+ that usage to <acronym>XSS</acronym> vectors. In 1.9.7, we have removed this option.
|
|
|
+ Graceful degradation is still supported, however, via a <acronym>noscript</acronym>
|
|
|
+ tag that embeds a <acronym>textarea</acronym>. This solution addressess all security
|
|
|
+ concerns.
|
|
|
+ </para>
|
|
|
|
|
|
- <para>
|
|
|
- In order to default to a more secure character encoding,
|
|
|
- <classname>Zend_Filter_HtmlEntities</classname> now defaults to <acronym>UTF-8</acronym>
|
|
|
- instead of <acronym>ISO-8859-1</acronym>.
|
|
|
- </para>
|
|
|
+ <para>
|
|
|
+ The takeaway is that if you were using the <varname>degrade</varname> flag, it will
|
|
|
+ simply be ignored at this time.
|
|
|
+ </para>
|
|
|
+ </sect3>
|
|
|
|
|
|
- <para>
|
|
|
- Additionally, because the actual mechanism is dealing with character encodings and not
|
|
|
- character sets, two new methods have been added, <methodname>setEncoding()</methodname>
|
|
|
- and <methodname>getEncoding()</methodname>. The previous methods
|
|
|
- <methodname>setCharSet()</methodname> and <methodname>setCharSet()</methodname> are now
|
|
|
- deprecated and proxy to the new methods. Finally, instead of using the protected members
|
|
|
- directly within the <methodname>filter()</methodname> method, these members are
|
|
|
- retrieved by their explicit accessors. If you were extending the filter in the past,
|
|
|
- please check your code and unit tests to ensure everything still continues to work.
|
|
|
- </para>
|
|
|
- </sect2>
|
|
|
+ <sect3 id="migration.19.security.zend.filter.html-entities">
|
|
|
+ <title>Zend_Filter_HtmlEntities</title>
|
|
|
|
|
|
- <sect2 id="migration.19.zend.filter.strip-tags">
|
|
|
- <title>Zend_Filter_StripTags</title>
|
|
|
+ <para>
|
|
|
+ In order to default to a more secure character encoding,
|
|
|
+ <classname>Zend_Filter_HtmlEntities</classname> now defaults to
|
|
|
+ <acronym>UTF-8</acronym> instead of <acronym>ISO-8859-1</acronym>.
|
|
|
+ </para>
|
|
|
|
|
|
- <para>
|
|
|
- <classname>Zend_Filter_StripTags</classname> contains a flag,
|
|
|
- <varname>commentsAllowed</varname>, that, in previous versions, allowed you to
|
|
|
- optionally whitelist HTML comments in HTML text filtered by the class. However, this
|
|
|
- opens code enabling the flag to <acronym>XSS</acronym> attacks, particularly in Internet
|
|
|
- Explorer (which allows specifying conditional functionality via HTML comments). Starting
|
|
|
- in version 1.9.7 (and backported to versions 1.8.5 and 1.7.9), the
|
|
|
- <varname>commentsAllowed</varname> flag no longer has any meaning, and all HTML
|
|
|
- comments, including those containing other HTML tags or nested commments, will be
|
|
|
- stripped from the final output of the filter.
|
|
|
- </para>
|
|
|
+ <para>
|
|
|
+ Additionally, because the actual mechanism is dealing with character encodings and
|
|
|
+ not character sets, two new methods have been added,
|
|
|
+ <methodname>setEncoding()</methodname> and <methodname>getEncoding()</methodname>.
|
|
|
+ The previous methods <methodname>setCharSet()</methodname> and
|
|
|
+ <methodname>setCharSet()</methodname> are now deprecated and proxy to the new
|
|
|
+ methods. Finally, instead of using the protected members directly within the
|
|
|
+ <methodname>filter()</methodname> method, these members are retrieved by their
|
|
|
+ explicit accessors. If you were extending the filter in the past, please check your
|
|
|
+ code and unit tests to ensure everything still continues to work.
|
|
|
+ </para>
|
|
|
+ </sect3>
|
|
|
+
|
|
|
+ <sect3 id="migration.19.security.zend.filter.strip-tags">
|
|
|
+ <title>Zend_Filter_StripTags</title>
|
|
|
+
|
|
|
+ <para>
|
|
|
+ <classname>Zend_Filter_StripTags</classname> contains a flag,
|
|
|
+ <varname>commentsAllowed</varname>, that, in previous versions, allowed you to
|
|
|
+ optionally whitelist HTML comments in HTML text filtered by the class. However, this
|
|
|
+ opens code enabling the flag to <acronym>XSS</acronym> attacks, particularly in
|
|
|
+ Internet Explorer (which allows specifying conditional functionality via HTML
|
|
|
+ comments). Starting in version 1.9.7 (and backported to versions 1.8.5 and 1.7.9),
|
|
|
+ the <varname>commentsAllowed</varname> flag no longer has any meaning, and all HTML
|
|
|
+ comments, including those containing other HTML tags or nested commments, will be
|
|
|
+ stripped from the final output of the filter.
|
|
|
+ </para>
|
|
|
+ </sect3>
|
|
|
</sect2>
|
|
|
</sect1>
|
|
|
<!--
|
thomas