- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Wed, 25 Aug 2010 18:46:54 -0400
2010/8/25 Kornel Lesi?ski <kornel at geekhood.net>:
> These cases can be secured without any new features in browsers (by escaping whitespace using numeric entities):
>
> function htmlescape($str) {
> ? ? ? ?return preg_replace('/[\s<>"\'&]/e','"&".ord("$0").";"',$str);
> }
That doesn't work in <script> for text/html, does it?
> I don't think that another escaping method would substantially improve PHP's situation. In my experience there are much more common problems that this won't solve:
>
> ? authors don't realize that echoed data may be dangerous, e.g. they expect to get a number, and it never occurs to them that field intended for numbers isn't guaranteed to contain only numbers. Some mistakenly believe that XSS is harmless (that it affects only attacker's own browser). They wouldn't use the new escaping method.
>
> ? PHP uses fundamentally flawed approach that requires authors to remember to escape all values all the time, and inevitably authors forget to do it sometimes. A better method, when forgotten, won't help at all.
>
> ? Novice authors don't understand escaping and end up using wrong approach (e.g. strip_tags() and filtering of input rather than output). Escaping method that makes escaped text opaque is going to be very confusing to authors who don't understand concept of escaping.
These are reasonable points. How many vulnerabilities would it
actually prevent in practice if htmlspecialchars() were replaced with
this everywhere? XSS is usually when you don't escape things at all,
not when you escape them in a slightly wrong way. Easy escaping in
<script> and <style> would be nice, though (or is there already some
way to do that?).
Received on Wednesday, 25 August 2010 15:46:54 UTC