Hi Rowan,
On 4 February 2014 14:53, Rowan Collins <[email protected]> wrote:
> I think part of the misunderstanding here is the distinction between "should
> PHP support an appropriate escape mechanism for this situation?" and "should
> the htmlentities() function be extended to be the appropriate escape
> mechanism for this situation?"
>
> The security requirement is for *users* to use appropriate escaping, and
> quoting, mechanisms for the output formats they use. The combination of
> quoted attributes and htmlspecialchars() with ENT_QUOTES is a secure
> escaping method, provided by the core of PHP.
>
> HTML5 *allows* users to use non-quoted attributes, but PHP does not
> currently have a built-in function which provides adequate escaping for that
> scenario. Such a function would need to do more than just escaping /, as
> others have pointed out; for instance, it would need to either escape,
> filter, or reject all forms of whitespace.
>
> I have no real opinion on what that function should be, except that I will
> personally never use it, because I will simply put quotes around my
> attributes and remove any need for it.
That's what we should be doing. Part of the concern with having a full
on unquoted attribute value escaping mechanism is what happens over
the course of an application's lifecycle. I'm absolutely of your
opinion, but others would argue that attribute escaping is defence in
depth against the day someone removes quotes without thinking. HTML5
has made that side of the fence more relevant.
If it were to be done, it would be a separate function other than
htmlspecialchars() which I assume is why htmlentities() as the local
greedy escaper makes an attractive carrier at face value. I don't
actually think it does fit there without redefining its purpose so a
separate function would be wiser.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative