Re: Default input encoding for htmlspecialchars/htmlentities

From: Date: Fri, 24 Aug 2012 21:23:36 +0000
Subject: Re: Default input encoding for htmlspecialchars/htmlentities
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-62462@lists.php.net to get a copy of this message
El 23/08/12 18:06, Rasmus Lerdorf escribió: > htmlspecialchars(), htmlentities(), html_entity_decode() and > get_html_translation_table() all take an encoding parameter that used to > default to iso-8859-1. We changed the default in PHP 5.4 to UTF-8. This > is a much more sensible default and in the case of the encoding > functions more secure as it prevents invalid UTF-8 from getting through. > If you use 8859-1 as the default but your app is actually in UTF-8 or > worse, some encoding that isn't low-ascii compatible then > htmlspecialchars()/htmlentities() aren't doing what you think they are > and you have a glaring security hole in your app. I don't see how passing utf-8 as latin1 gets into a security hole. The characters you want to replace (&'"<>) in utf-8 are the same as in latin1, and it can't get trickied with synchronizations. If it was passing latin1 to a function expecting utf-8 or "some encoding that isn't low-ascii compatible" then I see the hole, but not here. > So do we create a new default_input_encoding ini directive mid-stream in > 5.4 for this? Of course with the longer-term in mind that this will be > part of a unified set of encoding settings in 5.5 and beyond. Yes

« previous php.internals (#62462) next »