Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63178
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)
Message-ID: <505A8CA3.50101@gmail.com>
Date: Thu, 20 Sep 2012 13:25:23 +1000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Michael Shadle <mike503@gmail.com>
CC: =?UTF-8?B?UMOhZHJhaWMgQnJhZHk=?= <padraic.brady@gmail.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
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>
In-Reply-To: <CAKa35F6Z8FNbDuSJpkfRNLtwxsL4MCkEmrPASeS0fOkjfr9PsA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
From: davidkmuir@gmail.com (David Muir)

On 20/09/12 07:48, Michael Shadle wrote:
> On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady <padraic.brady@gmail.com> 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 
of 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 = getMyEncoding();?>
<table title="<?=str_escape($foo, ESCAPE_HTML_ATTRIBUTE, $enc)?>">
     <tr>
         <td><?=str_escape($foo, ESCAPE_HTML, $enc)?></td>
         <td><?=str_escape($bar, ESCAPE_HTML, $enc)?></td>
     </tr>
</table>


<!-- dedicated escaping functions -->
<?php $enc = getMyEncoding();?>
<table title="<?=escape_html_attribute($foo, $enc)?>">
     <tr>
         <td><?=escape_html($foo, $enc)?></td>
         <td><?=escape_html($bar, $enc)?></td>
     </tr>
</table>


<!-- OOP style -->
<?php $e = new Escaper(getMyEncoding())?>
<table title="<?=$e->escapeHtmlAttr($someTitle)?>">
     <tr>
         <td><?=$e->escapeHtml($foo)?></td>
         <td><?=$e->escapeHtml($bar)?></td>
     </tr>
</table>

I prefer the OO API since it's succinct, but if we are to have a 
procedural 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-use API like the filter extension.

Cheers,
David