Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63077
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5058AABA.1040406@sugarcrm.com>
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>
Date: Tue, 18 Sep 2012 13:14:24 -0400
Message-ID: <CAAyV7nHgJku5MqKY-D_Gk+DaSt-Wda3BJHsSzyS=yW6xENRi6w@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.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>
Content-Type: multipart/alternative; boundary=bcaec55242a09b612704c9fd05d1
Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
From: ircmaxell@gmail.com (Anthony Ferrara)

--bcaec55242a09b612704c9fd05d1
Content-Type: text/plain; charset=ISO-8859-1

Stas,

On Tue, Sep 18, 2012 at 1:09 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > No it's not. A filter removes, but escaping lets the original content
> > pass through unchanged, with the necessary in-band signalling to make
> > sure that its content is not treated as in-band signalling.
>
> Again, you are confusing particular implementation of a particular
> filter with the idea of filtering. Moreover, even existing filters do
> not match your description:
>

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.


> FILTER_SANITIZE_ENCODED, FILTER_SANITIZE_MAGIC_QUOTES,
> FILTER_SANITIZE_SPECIAL_CHARS, FILTER_SANITIZE_FULL_SPECIAL_CHARS,
> FILTER_SANITIZE_STRING, FILTER_CALLBACK
>
> But in general, look at implementation of filters anywhere - like Apache
> filters or IIS filters - nowhere it is said that filter can only remove
> data.
>

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.

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.

Escaping on the other hand is context dependent. You need a different form
of escaping for each output type (HTML, HTML attribute, XML, XML attribute,
XML processing instruction, JSON, database query, etc). So you cannot do a
generic escaping like you can do a generic filtering. Escaping should be
done as close to the edge as possible.

Check out this post I did a while ago with a pretty drawn out section
talking about the two concepts...
http://blog.ircmaxell.com/2011/03/what-is-security-web-application.html

Anthony

--bcaec55242a09b612704c9fd05d1--