Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63111
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5058CE31.5060401@lerdorf.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>
	<CAAyV7nHgJku5MqKY-D_Gk+DaSt-Wda3BJHsSzyS=yW6xENRi6w@mail.gmail.com>
	<5058B5A5.6090302@sugarcrm.com>
	<5058BA43.8010806@mrclay.org>
	<5058BBA6.4090702@sugarcrm.com>
	<5058BECC.8080409@lerdorf.com>
	<CALwr1GkwLPG1OuEJjCZGLWpNQeB-pcqhHB7UaSh2S78zjNWVOg@mail.gmail.com>
	<5058CE31.5060401@lerdorf.com>
Date: Tue, 18 Sep 2012 20:46:38 +0100
Message-ID: <CALwr1GkUtKLs72QHrVGZAs_kD2gTxyx1zHV1wOikUsOPeZ876Q@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Steve Clay <steve@mrclay.org>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
From: padraic.brady@gmail.com (=?ISO-8859-1?Q?P=E1draic_Brady?=)

Bear in mind the RFC, in userland (and likely any PECL ext) implements
the ESAPI rules. They've been hacked on a lot over the years which is
why I made sure they were followed exactly. It's very unlikely that a
browser bug could scupper these unless they allowed in more unencoded
characters to be taken advantage of. There are benefits to reusing
pre-peer review rules.

Paddy

On Tue, Sep 18, 2012 at 8:40 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> On 09/18/2012 03:28 PM, P=E1draic Brady wrote:
>> Hi Rasmus,
>>
>> On Tue, Sep 18, 2012 at 7:34 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wro=
te:
>>> 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. Bu=
t
>>> 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.
>>
>> I feel it needs to be reiterated that the escaper rules are very
>> predictable and very seldom change as the regular expressions in the
>> Zend\Escaper class demonstrate. Each is bound to official standards
>> for Javascript, CSS and HTML respectively and most of the rules,
>> defined using the OWASP's recommendations as implemented in ESAPI, are
>> really clearcut - escape everything except alphanumerics and a small
>> range of "safe" characters (CSS even has NO safe chars outside
>> alphanumerics). HTML and URL encoding are the only permissive variants
>> and these are already well known in PHP.
>
> Except the browsers all have different quirks. At the very least during
> the first year of its life this code it going to change a lot as the
> security community whacks away at it. This should start as a pecl
> extension so it can iterate rapidly and be available to PHP 5.3/5.4 users=
.
>
> -Rasmus
>



--=20
P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team