payload to innerHTML, you are hosed. Using the \u syntax, even if you
mess up and that blob of data finds its way to an innerHTML, nothing
nasty can happen. Basically this is a more robust context-protected way
I'm not sure this is correct - if you just write something like:
<script>
var = <?php json_encode($_GET['pleasehackme']) ?>;
myDomElement.innerHTML = var.content;
</script>
you are still in trouble, \u or not. Am I wrong?
You are correct. But there are two traps here. One is the example
above. Just a bad programmer not taking basic steps to secure data
being dropped into a full HTML context. Nothing PHP can do can protect
the application developer from that.
The second is the one I'm trying to address, wherein data that belongs
in a JS parsing context may (coincidentally) contain HTML parsable data.
For *whatever* reason, this data may accidently be echoed outside of a
JS context, or a parsing/rendering error may lead to the browser
switching unexpectedly to an HTML context. By outputting \u00XX instead
of <>&', the data remains valid (and syntacticly unmodified) for JS
parsing, but becomes impotent against exploitability in an HTML context.
It's a good potential win, with the only loss being an increase in
payload for those otherwise benign characters. Personally, I'd like to
make this the default behavior, but given the payload increase I'm
offering a compromise of using an option to enable this behavior only
when the user asks for it, thus preserving BC.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
