Req #69908 [Com]: Accept array for htmlspecialchars/htmlentities

From: Date: Wed, 24 Jun 2015 13:58:45 +0000
Subject: Req #69908 [Com]: Accept array for htmlspecialchars/htmlentities
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-193842@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=69908&edit=1

 ID:                 69908
 Comment by:         bishop@php.net
 Reported by:        yohgaki@php.net
 Summary:            Accept array for htmlspecialchars/htmlentities
 Status:             Assigned
 Type:               Feature/Change Request
 Package:            Strings related
 PHP Version:        Irrelevant
 Assigned To:        yohgaki
 Block user comment: N
 Private report:     N

 New Comment:

> Accept array and escape all elements when array is passed to them

Why not just:

array_map('htmlspecialchars', array ('&', '>',
'foo'));


Previous Comments:
------------------------------------------------------------------------
[2015-06-24 02:27:29] yohgaki@php.net

@ircmaxwell
I can understand your argument very well. Output security depends on "output context". 

This change is intended to escape relatively large number of variable at once. For example, HTML
tables that have a lot of variables. The objective is not for improving security, but performance.

We should balance security and performance/usability. Since I'm going to add array parameter
support for conversion functions, we need to consider consistency also.

I'll create RFC for this.

------------------------------------------------------------------------
[2015-06-23 15:27:59] ircmaxell@php.net

I think this is the exact wrong way to solve the problem. Very rarely do you want to actually just
do a "blind escape" of a bunch of variables. Instead, you need to know the context they
will be used in. By accepting strings only, these security sensitive functions encourage you to use
them exactly at the point of output, and hence in a contextual manner.

Instead, if you allow escaping arbitrary elements (arrays, objects, etc) then the contextual
guarantees disappear, as well as pushing the escaping further from the point of output. This makes
it harder to actually verify and reduces the overall security.

Not to mention that it makes the API a lot harder to follow and a lot more "magic". Both
of which are clear negatives on a security sensitive API.

------------------------------------------------------------------------
[2015-06-23 09:39:10] yohgaki@php.net

I can take care of them also.

I also notice that current  php_html_entities implementation is not optimal.
It can take 1st parameter as zval and convert int/float simply to string.

------------------------------------------------------------------------
[2015-06-23 09:08:13] requinix@php.net

What about all the other functions that take a string? add[c]slashes, bin2hex, md5, trim,
[raw]urlencode... And what about html_entity_decode and htmlspecialchars_decode?

------------------------------------------------------------------------
[2015-06-23 09:01:32] yohgaki@php.net

Description:
------------
htmlspecialchars/htmlentities only accepts string to be escaped.
Accept array and escape all elements when array is passed to them.




------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=69908&edit=1


Thread (8 messages)

« previous php.bugs (#193842) next »