Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63179
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <505A8CA3.50101@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>
	<505A8CA3.50101@gmail.com>
Date: Wed, 19 Sep 2012 22:11:48 -0600
Message-ID: <CAFMT4NoCw4+eVad0QYvfJ_rg-oLAaYUyx5KbXrPEwtZmb2J8mg@mail.gmail.com>
To: David Muir <davidkmuir@gmail.com>
Cc: Michael Shadle <mike503@gmail.com>, =?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: morrison.levi@gmail.com (Levi Morrison)

On Wed, Sep 19, 2012 at 9:25 PM, David Muir <davidkmuir@gmail.com> wrote:
> On 20/09/12 07:48, Michael Shadle wrote:
>>
>> On Tue, Sep 18, 2012 at 10:32 AM, P=E1draic Brady <padraic.brady@gmail.c=
om>
>> 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
>> 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)
>>
> I'm on the fence with a default encoding. I tend to always use UTF-8, so
> would probably just use the default. But that means I become less aware o=
f
> encoding being central to the issue, and therefore much easier to
> accidentally leave it as UTF-8 when it should be something else.
>
> -1 on the flag based api, though. Would much rather have dedicated
> functions. It's easier to read, and less verbose.
>
> <!-- str_escape with flags -->
> <?php $enc =3D getMyEncoding();?>
> <table title=3D"<?=3Dstr_escape($foo, ESCAPE_HTML_ATTRIBUTE, $enc)?>">
>     <tr>
>         <td><?=3Dstr_escape($foo, ESCAPE_HTML, $enc)?></td>
>         <td><?=3Dstr_escape($bar, ESCAPE_HTML, $enc)?></td>
>     </tr>
> </table>
>
>
> <!-- dedicated escaping functions -->
> <?php $enc =3D getMyEncoding();?>
> <table title=3D"<?=3Descape_html_attribute($foo, $enc)?>">
>     <tr>
>         <td><?=3Descape_html($foo, $enc)?></td>
>         <td><?=3Descape_html($bar, $enc)?></td>
>     </tr>
> </table>
>
>
> <!-- OOP style -->
> <?php $e =3D new Escaper(getMyEncoding())?>
> <table title=3D"<?=3D$e->escapeHtmlAttr($someTitle)?>">
>     <tr>
>         <td><?=3D$e->escapeHtml($foo)?></td>
>         <td><?=3D$e->escapeHtml($bar)?></td>
>     </tr>
> </table>
>
> I prefer the OO API since it's succinct, but if we are to have a procedur=
al
> API as well, lets make it concise and clear. The last thing we want for
> solving the no 1 security threat to web-apps is a confusing and hard-to-u=
se
> API like the filter extension.
>
> Cheers,
> David
>
+1 to most of what you said.

I will disagree on the filter extension. Its main problems are lack of
publicity and functions with similar names that don't do what you
would expect (Consider `is_int`).  I use FILTER_VALIDATE_BOOLEAN and
FILTER_VALIDATE_INT on a regular basis, and have used other filters. I
will agree it's API could have been better, but it is not confusing in
my opinion.

I do want to make it clear that I support a simple, clean API if we do
implement more escaping functions.