Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34936
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain users.sourceforge.net from 213.197.162.99 cause and error)
Message-ID: <37582.78.61.224.253.1201331756.nsm@avilys.eik.lt>
In-Reply-To: <479A613C.8030604@zend.com>
References: <200801241426.39756.arnaud.lb@gmail.com>
    <479A613C.8030604@zend.com>
Date: Sat, 26 Jan 2008 09:15:56 +0200 (EET)
To: internals@lists.php.net
User-Agent: NaSMail/1.4
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] [PATCH] Bug #43896 htmlspecialchars returns empty 
     string on invalid unicode sequence
From: tokul@users.sourceforge.net ("Tomas Kuliavas")

>> Should really theses functions discard the whole string for a single
>> incomplete sequence ?
>
> I think since it is not possible to recover true content of the string,
> it is ok to return failure value. Cutting it in random places or
> ignoring problems doesn't seem a good idea - it might lead to all kinds
> of nasty things, such as security filtering checking one data and
> database getting entirely different data.

Instead of using simple sanitizing function users are forced to check for
errors. How good is that? It makes code complex or unreliable.

htmlspecialchars() and htmlentities() are not used to sanitize database
data. What kind of errors you expect in htmlspecialchars()? I think
supported charsets don't have alternative symbols in 0x22, 0x26, 0x27,
0x3C, 0x3E. Only CJK charsets and htmlentities might have issues. With any
other charset you know start and end byte of symbol. If you think that
broken utf-8 can cause issues, strip or sanitize broken symbols.

If users detect error in htmlspecialchars(), they will use str_replace()
in order to provide some failsafe instead of losing whole text and it
won't solve security issues.

-- 
Tomas