On 20 June 2016 17:40:05 GMT+01:00, "Михаил Востриков"
<[email protected]> wrote:
>Actually, htmlspecialchars() is needed in all three cases:
...
>You may not write htmlspecialchars together with urlencode just because
>urlencode encodes all special characters with its own way.
So, not needed in all 3 cases then...
>Imagine that urlencode does not encode quotes - what function should we
>call for its result?
Ideally, an escape filter that performs both functions; if the aim is to make
things easier, I shouldn't need to think about the need to nest two escape
functions. If I still have to use non-obvious combinations of magic syntax plus
function calls, the claim of "secure by default" doesn't really stand up. The ~
becomes nothing more than an alias that I still need to remember when to deploy.
<script>$('[data-thing-id="<?~ $thing['name'] ?>]').on('click',
function(){doThing('<?~ $thing['name'] ?>'});</script>
I'm pretty sure the tempting syntax is actively harmful in that situation...
>The fact itself, that there were many discussions about it, indicates
>that
>it is a necessary feature.
Popularity is not the same thing as necessity. More relevantly, even when we
agree on the problem, the simple solution isn't always the best, sometimes it
pays to think a bit more broadly about the problem space. Larry's escaper
registration is one example of that.
HackLang's XHP is another - rather than thinking about escaping as an action,
it gives the compiler richer knowledge of the structure, so it can "know" the
right escape syntax. If the compiler could look at my previous example and
recognise the attribute, URL, script, and text contexts itself, then you really
would have security-by-default. Unfortunately, that too is tricky to generalise
- what is the correct escape method for an attribute named "data-my-action"...?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
