ZF-12054: Possible XSS in Zend_View::escape()

Description

<?php
require_once "Zend/Loader/Autoloader.php";
Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true);
$view = new Zend_View();
$userInput = "' onmouseover='alert(/XSS/)";
?>
Test

Expected output:



Actual output with ZF 1.11.8:

Which results in Javascript being executed on mouse over.

Comments

This is not an XSS vector which has resulted from Zend Framework code.

The escape function is intended to be used to convert html special characters into their entites, such as < into &lt; thus preventing injection of further tags into content. If it were to also add slashes, (to ' or ", or both?) then this would affect the output of many many applications, littering them with superflous slashes which are not actually needed.

Unfortunately, you have decided to use it as a part of escaping a html attribute, not an entire block, it is therefore your responsibility to ensure that user input cannot prematurely end the quoting. (and this should be done through whitelisting your user input).

To make this clear, consider this example:

$comments = array("I don't like XSS, it puts a crimp in my day");

foreach ($comments as $comment) { echo $view->escape($comment), "\n"; }

You'd expect: I don't like XSS, it puts a crimp in my day

Due to your proposed fix to your problem: I don\'t like XSS, it puts a crimp in my day

This is not desireable.

Closing as not an issue after getting some agreement from other contributors on IRC.

I understand how it works and why it does not work in this case. The problem is that (as average developer) when I call $this->escape($var) I assume it's safe to echo the code. There should at least be a warning in the manual for escape(), that you need to call addslashes whenever using escaped content inside tag's attribute. Typical use - user's name as image alt/title - Jim O'Reily, Dwayne "The Rock" Johnson. You can't filter those. At least this problem is enough to debate whether to hide the real implementation in escape method or use the plain old htmlspecialchars without any wrapper.

Reopened pending security review.

Call to htmlspecialchars() or htmlentities() from Zend_View_Abstract::escape uses ENT_COMPAT in preference to ENT_QUOTES which would have replaced single quotes with semantically equivalent numeric entities. Unless double quoted attributes are enforceable by the framework, it seems reasonable to switch the flag.

Please note that all security related issues should be reported to zf-security@zend.com in preference to the issue tracker. You can read our security policy at http://framework.zend.com/security.

I'm sorry. Didn't knew it. My appologies.

No worries . I've email the zf-security address with a quick note on this, and copied you in so you can track its progress.

To clarify this, the expected output is:


Test

Jakub, noted ;). JIRA just decoded that into a forward slash I think for the comments above.

Where does this issue stand? Are there any mitigation strategies we could realistically include in 1.12?