On Wed, 25 Aug 2010 22:52:42 +0100, Kornel Lesiński <[email protected]>
wrote:
<script>
elmt.innerHTML = 'Hi there <?php echo htmlspecialchars($name) ?>.';
</script>
These cases can be secured without any new features in browsers (by
escaping whitespace using numeric entities):
I realized I was wrong about this one. It won't prevent script injection
in JS strings (in places where entities are decoded, including <script> in
XML), because entity will be changed to plain text before JavaScript is
tokenized.
For this reason, base64 entities won't solve this problem either, unless
they're specifically defined as JavaScript construct, not only HTML
construct (and I think such mix of parser would be bad).
If parser decoded such entities in <script> (like XHTML does):
foo = '&%JztldmlsKCk7Jw==;'
then decoded string passed to JS parser would look like:
innerHTML = '';evil();''
which defeats purpose of the encoding.
OTOH if HTML parser didn't decode these entities in <script> (which is
current text/html behavior), then JS would get undecoded string (i.e.
foo.charAt(0) == '&').
--
regards, Kornel
