Error page does not sanitize HTML, passes through potentially malicious Javascript
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Zope 2 |
Fix Released
|
High
|
Tres Seaver |
Bug Description
Hi,
We got a bug report to the Plone security team, which seems to be a problem in Zope's error handling. By manipulating the Plone search in a way that it triggers a UnicodeDecodeError (which we should of course fix on our end), it falls back to the standard Zope error page, which then executes Javascript in the browser.
The original report below:
> The following Scripts and respective Query String parameters are
> vulnerable;
>
> sitename changed to xxx
>
> Vulnerable Application: http://
>
> Example URL:
> http://
>
> Vulnerable Param: sort_on
> Weight: 8 (out of 10)
>
> Example URL:
> http://
>
> Vulnerable Param: sort_on
> Weight: 8 (out of 10)
>
>
> Both these examples return the following html to the browser;
>
> Unknown sort_on index (Date">
> (Also, the following error occurred while attempting to render the standard
> error message, please see the event log for full details: 'ascii' codec
> can't encode character u'\ufffd' in position 227: ordinal not in range(128))
Alec Mitchell says:
> It appears to be a real issue. The combination of a UnicodeDecode
> error preventing the normal error display and the traceback sending
> unquoted html to the browser. Not sure we can fix easily at the Plone
> level though. See for example:
> http://
I can not trigger this issue - neither with the given link to ploneconf2009.de nor on one of our sites.