Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63098
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.220.170 cause and error)
Message-ID: <5058BECC.8080409@lerdorf.com>
Date: Tue, 18 Sep 2012 14:34:52 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: Steve Clay <steve@mrclay.org>, 
 PHP Internals <internals@lists.php.net>
References: <CALwr1Gn4OmHP=Qa7NKzpbkq+w8FEjUMZ3v678bbZVOGM23G35g@mail.gmail.com> <5058A697.30903@sugarcrm.com> <CAAyV7nF82MW1gRpVpiVooCNyj7YE-eVDqjzqFX0m3X1J7Kp_UA@mail.gmail.com> <5058A8B8.3070404@sugarcrm.com>	<5058A97A.4080900@ajf.me> <5058AABA.1040406@sugarcrm.com> <CAAyV7nHgJku5MqKY-D_Gk+DaSt-Wda3BJHsSzyS=yW6xENRi6w@mail.gmail.com> <5058B5A5.6090302@sugarcrm.com> <5058BA43.8010806@mrclay.org> <5058BBA6.4090702@sugarcrm.com>
In-Reply-To: <5058BBA6.4090702@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 09/18/2012 02:21 PM, Stas Malyshev wrote:
> Hi!
> 
>> Filter has already gone down this road--I doubt the value added by having a second, much 
>> more verbose way to call htmlspecialchars()--but I don't see why we must continue down 
>> that path.
> 
> So, you don't think there should be second, more verbose way to call
> htmlspecialchars - that's why we should add third, more verbose way to
> call htmlspecialchars? Somehow this does not sound convincing to me.

And note that there is actually a good reason. By having
htmlspecialchars as a filter you can use it as a default input filter.

A strict default filter acts as a safety net against typical XSS flaws.
If a developer forgets to apply the correct filter/encoding/escaping
(whatever you want to call it) mechanism, then the default filter makes
sure the most common cases are covered. Some people make the mistake of
associating default filtering like this with always storing escaped data
in the backend which simply isn't the case. It is nothing more than a
safety net and a way to make it easier to audit data filtering by
forcing developers to specify the escaping, if any, they want on every
piece of input data.

If we want to add more filters for more specific purposes, I am not
completely against it, although the more specific they get the more
churn there will be. We are not going to be able to kick out weekly
releases to address every new nuance of these very specific filters. But
they should be implemented as filters compatible with the filter
extension so people can use them within that existing context. That
doesn't preclude a more approachable function alias from also calling
them, of course, much like the htmlspecialchars case.

-Rasmus