Req #69450 [Wfx]: Default to ENT_SUBSTITUTE for htmlspecialchars()

From: Date: Wed, 15 Apr 2015 14:33:48 +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-192104@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 User updated by: olafvdspek at gmail dot com 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: If the program contains a security bug then halting the program seems one of the best possible solutions. Previous Comments: ------------------------------------------------------------------------ [2015-04-15 14:26:06] rasmus@php.net Because it is typically called on user-supplied data and having end users being able to fatal your app and/or cause a log storm is a really bad idea. ------------------------------------------------------------------------ [2015-04-15 08:44:41] olafvdspek at gmail dot com @Rasmus: Why does it not log an error and why does it not halt execution? ------------------------------------------------------------------------ [2015-04-15 06:28:51] rasmus@php.net Yes, from a security perspective, trying to fix a broken byte stream with any sort of guesses and replacement characters is a non-starter. You simply don't do it. Certainly not by default. If someone really wants to try to fix broken input they need to do so explicitly and hopefully they understand the risk they are taking. The most common example char replacement problems is Internet Explorer doing substitution on broken UTF8 in IE5 and IE6. For example, something like %E0%22%3E which is byte 0xE0 followed by " and > would get substituted with a �. So what you say? Well, by swallowing the "> you have yourself a glaring XSS since all subsequent characters are now no longer inside a quoted parameter in a tag. And IE replaced those 3 bytes because the E0 byte is the start of a 3-byte UTF8 sequence, so a user could XSS IE simply by adding a %E0 to GET/POST data. ------------------------------------------------------------------------ [2015-04-15 05:52:09] yohgaki@php.net I should have post undebatable example. Anyway, don't forget there is encoding includes "\" in multibyte stream. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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

« previous php.bugs (#192104) next »