Case9225Example.war = JSF example

Case9225Example.war = ICEfaces example

Project source code

Sample cross site script:
"<SCRIPT SRC=http://ha.ckers.org/xss.js></SCRIPT>";

The attached cases are built for glassfish.

It may be possible to use DOM userData to indicate whether a given text node should be escaped on output or not.

We could add a method to DOMUtils, which would check a context param, and then conditionally call DOMUtils.escapeAnsi. In ICEfaces 1.8.2, the default would be to not escape, and in ICEfaces 2, the default would be to do escaping. In either release, escaping can be enabled or disabled. Then, all of the DOM API compat components, that erroneously do not do escaping, would be modified to use this new method. We would just search for the DOM API usage where text nodes are created, and add this, where appropriate. That way backwards compatibility can be preserved, and security enhanced (mutually exclusively).

Customer comment/suggestion:

Created By: Markus Günther (07/07/2010 1:07 AM)
Hi, in the meantime we have added explicit filtering of the input and output in all getter and setters of the application. Of course it would be helpful if such a task is treated by the library as it is general stuff which must be applied to almost all GUI input and output controls.

We 've implemented this by usage of the official OWASP ESAPI library which is common availalbe and does this job. I would recommend IceFaces to add such functionality in a future release as this is more and more a very hot issue for web applications and most developers are not aware of that. So it is a big plus using the library (eg. only for IceFacesEE users .

See: http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Please let me know once you have a decision how you proceed with this security issue.

Investigate compat to determine if the concern remains with ICEfaces 2.0.

Verified problem to still be present with ICEfaces 2.0 compat.

For instance, the following string will result in script execution when set on the selectOne:

<script>alert('hello')</script>

Attached file can be unzipped in component-showcase expanded directory to reproduce the problem.

Code from compat/core/src/main/java/com/icesoft/faces/renderkit/dom_html_basic/MenuRenderer.java

Text labelNode = doc.createTextNode(label == null ? valueString : label);

A DOM Text object is created directly from the component valueString. Most calls to createTextNode are invoked via domContext.createTextNode(), many are of the form

domContext.getDocument().createTextNode(detail);

The legacy DOMContext API could be modified to perform escaping and the few remaining cases that operate on the DOM directly could be replaced with DOMContext versions.

Compat components have been modified to use createTextNodeUnescaped only when necessary. Note that there are possible script injection attacks through some of the scripts generated by components, for instance:

Ice.FCKeditor.register ('iceform:iceInpRchTxt', new Ice.FCKeditor('iceform:iceInpRchTxt', 'en', '', '/component-showcase/icefaces/resource/LTQ5MTYyMDg1Mw==/','600', '275', 'Default', 'null', 'silver'))

The 'null' in the above consists of options passed to the editor component. If these options are dynamically generated from user input, there is the possibility of script injection attacks.

The fix was not overly complex and could be back-ported to ICEfaces 1.8 if required.