Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63164
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <72B22976-6F00-4EF5-88B3-140576CFE4E7@gmail.com>
References: <CAO1hux8mmUsy4badiNjxTGMubaduD1gkgbw4ZK1Me_MwGwLybA@mail.gmail.com>
	<CALtuQzC4e2Sn_BHinFAPdVrz8Oc_d6wCqTr=AscMChH29NSENw@mail.gmail.com>
	<CAO1hux9+4QK2sVX9+4110ksa9qDpUpfDhFJvyzkXcBHrFoFWvg@mail.gmail.com>
	<0960EAA5-17FF-4E0F-9DDE-BB93D13EA02B@gmail.com>
	<CAO1hux9t9refYHYnKhY0725MvRm88ab85Ng23LCvnjDJxqQA7g@mail.gmail.com>
	<CALwr1GnjjjMbK8-VkVO57meDAgDn8PSPoWdj2DjYMB7F01dP4Q@mail.gmail.com>
	<CAPwsocGs=5-JfpSSewDRaNC0KaoNF1okBD8-E27fx5U=9f6sgw@mail.gmail.com>
	<72B22976-6F00-4EF5-88B3-140576CFE4E7@gmail.com>
Date: Wed, 19 Sep 2012 18:55:59 +0100
Message-ID: <CALwr1GmhT5X4eqPwhOtMuj_C37bxDZ2tHnrzm9JyqUo19tu7pw@mail.gmail.com>
To: Michael Shadle <mike503@gmail.com>
Cc: Leigh <leight@gmail.com>, "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] Re: RFC: Implementing a core anti-XSS escaping class
From: padraic.brady@gmail.com (=?ISO-8859-1?Q?P=E1draic_Brady?=)

Hi Michael,

>> It feels like this is just using classes for the sake of using
>> classes, adding an unnecessary layer of complexity (and discussion)
>> for no real reason except that is the RFC authors preference.
>
> +1
>
> First the discussion was filtering vs escaping. Now it is about how to im=
plement it as a class etc.
>
> I don't understand why people have any issue with it being a core procedu=
ral function. You can call that from your OO code just fine. Just like any =
other core procedural function.

I have never once expressed a problem with this being a set of
procedural function. Not once. The RFC offers some suggested function
signatures. So nobody has expressed any issues and nobody has insisted
that you be required to use a class or object.

> There is no reason it has to be OO. OO has to call procedural functions a=
lready (string functions, array functions, curl, json, etc etc); but us pro=
cedural purists don't have to call OO methods and classes if we don't need =
to (except now some of the DateTime IIRC which bugs me :p)

Then please - call the functions as defined in the RFC.

> Anyway how hard is it to use something akin to the filter functions? That=
's what constants/flags are for.

The RFC addresses escaping, not input filtering. Yes, there is a fine
line between them but the filter method requires constants, options,
and we would then need to later in character encoding. The resulting
mutation would be a step backwards in my opinion in guiding users
towards the secure use of escaping in applications.

> Call it str_escape(string, flags optional, encoding optional) and be done=
 with it. Since it won't be useful to have escape_var or escape_input type =
of differentiation and this seems like it could just fit under the string f=
amily of functions (I am a fan of namespaced functions by prefix)
>
> After that it seems like the discussion would be:
> 1) do we even need encoding or is UTF8 just fine
> 2) what are the flags to be defined for different escaping methods

Correct encoding is essential. The entire planet does not use UTF-8,
and UTF-8 is not the same as other encodings once you get over the
theoretical perfection that should exist and meet the rebels:
browsers. Please bear in mind that using the correct encoding has been
preached for many many years as a minimum requirement in secure
escaping for PHP.

Paddy

--=20
P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team