Req #69450 [Wfx]: Default to ENT_SUBSTITUTE for htmlspecialchars()
| From: | yohgaki@php.net | Date: | Wed, 15 Apr 2015 05:52:09 +0000 |
| Subject: | Req #69450 [Wfx]: Default to ENT_SUBSTITUTE for htmlspecialchars() | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-192071@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=69450&edit=1
ID: 69450
Updated by: yohgaki@php.net
Reported by: olafvdspek at gmail dot com
Summary: Default to ENT_SUBSTITUTE for htmlspecialchars()
Status: Wont fix
Type: Feature/Change Request
Package: Output Control
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
I should have post undebatable example.
Anyway, don't forget there is encoding includes "\" in multibyte stream.
Previous Comments:
------------------------------------------------------------------------
[2015-04-15 05:49:08] yohgaki@php.net
More detailed example.
<multibyte start byte> + "<"
What should happen? Replace <multibyte start byte>? or Replace <multibyte start byte> +
"<"?
Neither is correct and will break structured text.
------------------------------------------------------------------------
[2015-04-15 05:45:16] yohgaki@php.net
Generally speaking, escape functions cannot determine if a invalid byte in multibyte stream is
legitimate or not.
Besides, invalid multibyte stream should be detected while input data handling. This is the best
practice. Otherwise, apps may be affected by char encoding based attack any places in the software
including low level lib's vulnerability.
BTW, current chrome (since about 2 years ago) won't output any if input is broken badly because
it's impossible to make sure security.
Returning blank string perfectly makes sense for security stand point.
------------------------------------------------------------------------
[2015-04-14 20:28:13] nikic@php.net
I also think that ENT_SUBSTITUTE is a more reasonable default behavior. Could you elaborate in which
circumstances it will cause broken output?
------------------------------------------------------------------------
[2015-04-14 20:13:15] olafvdspek at gmail dot com
If that's the case wouldn't it be even better to halt the script?
Returning empty strings ALSO has the risk of broken output. Even worse, broken output is basically
guaranteed.
------------------------------------------------------------------------
[2015-04-14 19:52:03] yohgaki@php.net
Replacing any invalid byte sequence in string has risk of broken output. i.e. Broken html
structures, etc.
If you would not want to have empty outputs from htmlspecialchars, validate all of your inputs. You
can replace invalid multibyte sequence optionally. i.e. Use mb_convert_encoding().
This is the optimal way to handle text.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=69450
--
Edit this bug report at https://bugs.php.net/bug.php?id=69450&edit=1