Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63176
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKa35F6Z8FNbDuSJpkfRNLtwxsL4MCkEmrPASeS0fOkjfr9PsA@mail.gmail.com>
References: <CALwr1Gn4OmHP=Qa7NKzpbkq+w8FEjUMZ3v678bbZVOGM23G35g@mail.gmail.com>
	<alpine.DEB.2.02.1209180809010.28929@whisky.home.derickrethans.nl>
	<CALwr1GnjwyE=yipK6UNkOm9m31LDDbpbcdgmr_nf0cUo+zOedw@mail.gmail.com>
	<CALwr1G=DOKmjudFFEAFY+6hmUh3q+qNe1ntWY1FLXP5GChLZdA@mail.gmail.com>
	<CAMUwpuSfd1U6aA_7o6d2jGm-i0PsLAf1MqKF8zvtcfzGFMGEXQ@mail.gmail.com>
	<0AC6EB13-3588-403B-BE73-968F12C7B7AF@gmail.com>
	<CALwr1G=0L-u7vu4gUrfO51DP50anfUbkPS+mHePzen6Aih4e7g@mail.gmail.com>
	<CAKa35F6Z8FNbDuSJpkfRNLtwxsL4MCkEmrPASeS0fOkjfr9PsA@mail.gmail.com>
Date: Thu, 20 Sep 2012 02:05:12 +0100
Message-ID: <CAKxcST8kF+WcqSphSTghk=US8Zz0iUCR1q4Wf91LfqM5gOMHRw@mail.gmail.com>
To: Michael Shadle <mike503@gmail.com>
Cc: =?ISO-8859-1?Q?P=E1draic_Brady?= <padraic.brady@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] RFC: Implementing a core anti-XSS escaping class
From: dragoonis@gmail.com (Paul Dragoonis)

On Wed, Sep 19, 2012 at 10:48 PM, Michael Shadle <mike503@gmail.com> wrote:
> On Tue, Sep 18, 2012 at 10:32 AM, P=E1draic Brady <padraic.brady@gmail.co=
m> wrote:
>> Hi Michael,
>>
>> See the link near the bottom of the RFC - even htmlspecialchars() has
>> unusual behaviour that's potentially insecure. I have no objections to
>> there being functions, of course, and the RFC makes that clear.
>> However, many programmers like me are obsessed are objects so having
>> an SPL class will obviously be near and dear to my design patterned
>> heart ;).
>
> After looking over the RFC finally, would it be that crazy to consider
> this an extension of the standard string functions?
>
> str_escape($string, $encoding, $flags) or probably better
> str_escape($string, $flags, $encoding) - since encoding could be

I'm also proposing escape_var(), just like filter_var(). If it's
str_escape() then that's still sane, it's consistent and that's all
that matters. :-)

- Paul.


> defaulted to UTF-8, but flags are really what differentiate the
> behavior...
>
> Then there is not a handful of functions but rather one that can be
> used as the abstraction point and the flags passed to it will change
> it's behavior, much like the filter functions.
>
> (I just see this falling under one solid defacto escape function
> standard, and it could live by itself as "escape" or something, or as
> it operates on strings, prefix it as such)
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>