Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63085
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5058A697.30903@sugarcrm.com>
References: <CALwr1Gn4OmHP=Qa7NKzpbkq+w8FEjUMZ3v678bbZVOGM23G35g@mail.gmail.com>
	<5058A697.30903@sugarcrm.com>
Date: Tue, 18 Sep 2012 18:40:28 +0100
Message-ID: <CALwr1GkM6ccsR0XJ9V4dzf8cPf3Ak-epfmEC1d0jKMbwSn0S9Q@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <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?=)

Hi Stas,

This is not an input filter and PHP already suffers the same
outrageous disadvantages by offering htmlspecialchars(),
rawurlencode(), etc. The rules for escaping are well established and
DO NOT change overnight. Those for Javascript and CSS are in their
respective standards. Those for HTML/XML have been known since the 90s
and still haven't changed. PHP seems quite happy about offering
encoding mechanisms if anything - where did json_encode() spring from?

Browser defects are not PHP's problem.

Folk seem to be missing the point that this is output oriented to a
well understood set of rules.

Paddy



On Tue, Sep 18, 2012 at 5:51 PM, Stas Malyshev <smalyshev@sugarcrm.com> wro=
te:
> Hi!
>
>> I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
>> The RFC is a proposal to implement a standardised means of escaping
>> data which is being output into XML/HTML.
>
> We already have filter extension. Is it really necessary to invent yet
> another way of filtering data?
>
> Also, a problem with putting code of this complexity in core would be
> that if it every had a defect - e.g. we forgot to account for some weird
> browser quirk that does not follow RFCs, or some strange encoding
> combination, or just a plain bug - it would be very hard for the users
> to mitigate without upgrading PHP - which is not always under their
> control. When using PHP code, they could just d/l new ZF class, but with
> core implementation it'd be much harder.
>
> So far I am not convinced we should really do it. But if somebody
> creates PECL extension and it proves popular, it may be merged into core
> once it does.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227



--=20
P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team