Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63087
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.133 as permitted sender)
Message-ID: <5058B5A5.6090302@sugarcrm.com>
Date: Tue, 18 Sep 2012 10:55:49 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Anthony Ferrara <ircmaxell@gmail.com>
CC: Andrew Faulds <ajf@ajf.me>, =?ISO-8859-1?Q?P=E1draic_Brady?=
 <padraic.brady@gmail.com>, 
 "internals@lists.php.net" <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>
In-Reply-To: <CAAyV7nHgJku5MqKY-D_Gk+DaSt-Wda3BJHsSzyS=yW6xENRi6w@mail.gmail.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: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> No, he's not. Filtering and escaping are two very significant concepts
> in security. Just because PHP implemented some escaping concepts into
> the filter function does not mean that the concerns are co-related.

Again, you are taking very narrow definition of filterting, which is not
justified by anything but your very narrow use case, and try to present
it as if this is the only meaning filtering has (despite numerous
examples of using of filters in more generic sense) and that because of
this we need to duplicate APIs we already have, just because you can use
them in different context. To me, it makes no sense - you can apply data
filtering anywhere. If for your specific purpose of explaining how to
make better security architecture you choose to define "filtering" and
"escaping" as narrow distinct concepts, this is fine. This does not mean
that we can not use existing filter extension - with already implemented
methods doing exactly what is needed to be done - because they are to be
used in context which you call "escaping".

> Actually, that's the basic definition of a filter (from a security
> context). Just because people implemented other things and called them
> filters does not make them filters in the context of this discussion.

It is your definition of a filter, which is in no way "basic" or universal.

> The other point that you seem to be missing is that filtering is generic
> for an application. You would apply the same filters for content that
> came in from an HTTP post as content that came in from a JSON API call.
> The data is what's filtered for your application.

Again, nowhere it is said that you can not apply different filters to
different data or different context. Again, you narrow down definition
of filtering, to which I see no purpose unless you seek to arrive at
pre-determined conclusion that we need to duplicate APIs because it's
called "filter".

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227