Stanislav Malyshev wrote:
You're absolutely correct that this won't save us from brain-dead
engineers, what it will save us from is broken browsers which
misinterpret otherwise legitimate data and get broken out of their
proper context. (Yes, I've seen browsers do exactly this, and you can
probably guess which versions)
Could you explain in which context? I.e. say I had a broken browser, and
some JSON data having <foo> inside it - in which context that could get
me into trouble?
I can't because I don't know of any successful vectors *currently*. I
also would have sworn that echoing htmlentified data was safe....until I
came across a browser where it wasn't.
Since I can't show you a known problem that this *will* absolutely fix,
I'm not suggesting that default behavior be so paranoiac. I'm just
suggesting that users have the option to apply belt-and-suspenders logic
if they feel so inclined.
That said, after yesterday's post I realized that it *should* be safe
enough to do:
$str = str_replace(array('<','>',"'", '&'),
array('\\u003C','\\u003E','\\u0026','\\u0027'), json_encode($data));
That feels terribly hacky though and I'd really rather perform the
escaping inside json_encode() while acting on the actual value.... just
seems more appropriate to me...
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
