Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94153
Return-Path: <larry@garfieldtech.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 44159 invoked from network); 20 Jun 2016 16:07:47 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 20 Jun 2016 16:07:47 -0000
Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
X-PHP-List-Original-Sender: larry@garfieldtech.com
X-Host-Fingerprint: 66.111.4.27 out3-smtp.messagingengine.com  
Received: from [66.111.4.27] ([66.111.4.27:54078] helo=out3-smtp.messagingengine.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 8A/E3-16093-2D418675 for <internals@lists.php.net>; Mon, 20 Jun 2016 12:07:46 -0400
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
	by mailout.nyi.internal (Postfix) with ESMTP id 02A2B2049A
	for <internals@lists.php.net>; Mon, 20 Jun 2016 12:07:43 -0400 (EDT)
Received: from frontend2 ([10.202.2.161])
  by compute1.internal (MEProxy); Mon, 20 Jun 2016 12:07:44 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=content-transfer-encoding:content-type
	:date:from:in-reply-to:message-id:mime-version:references
	:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=uroleO1C/ASa2dc
	SyecF6WIbVCo=; b=VbiffDr11Iw2qb1pDmH0wsh5w5MOLgiqdgIZjmFSevpzK0I
	1bhrvIgE0BDHSjxLZKOsXMDG6Gtd3J28snAP4DVrkW1+cA/y9ZP1Dvi8pRlXdK69
	50tyqDVaLlhdfiqCuOI+Kx4YOe8lAHSb5IC6mEcH6M+CvUElxDm/KcWVtDjI=
X-Sasl-enc: jQ4Zd37mZkjgiY3HAzAc3fHEJwzVTYTTqgZFj/S0e/gh 1466438863
Received: from [192.168.42.5] (c-50-178-40-84.hsd1.il.comcast.net [50.178.40.84])
	by mail.messagingengine.com (Postfix) with ESMTPA id 3A01ACCD2E
	for <internals@lists.php.net>; Mon, 20 Jun 2016 12:07:43 -0400 (EDT)
To: internals@lists.php.net
References: <CAEDdnaX_KbaZB=3WzFAp73E0dCxx5zuoqMbPbakMUGpHyRPJFg@mail.gmail.com>
 <CADqTB_ijxN_ZVcAdLrpnejtYNO2x6Z1Q4PcnARCRE+etDuhF3w@mail.gmail.com>
 <CANUQDCjgSohsYWmkWOLfdL+9Jzio_uY-vnYVc4fzd6kmGaL46g@mail.gmail.com>
 <CADyq6sJmj=bnN+65-59UrsJuuc8dYxP3HPqNOktjnRFexcFVWA@mail.gmail.com>
 <CAEDdnaUz3_6sVN07G+KF15B0avDoTV85UiR1mLie-F3orMrUog@mail.gmail.com>
 <57665E36.60302@lsces.co.uk>
 <CADyq6sKPDtC5Q=OV7D5qQF2W6XgJCyKXpatU0KB=StveXA8pdw@mail.gmail.com>
 <5766D311.6030503@lsces.co.uk>
 <CAKws9z3UyQxiXpC8Jbv5tf6guzn+pgdp76B49ZsUdS08s-Jtaw@mail.gmail.com>
 <CAMPTd_A86iCrytrHwp87GyjLU8FX+BbLsdREOpNfUc=_McRMow@mail.gmail.com>
 <CAEDdnaUi5hvOAkkPWWk3YVNxMjsCbntB-W70a8sPXFkKHJGY8w@mail.gmail.com>
 <CAMPTd_DADkueRwN9AR0VNtGWg+Q58ab7JR=7meaj7fTohGZsww@mail.gmail.com>
 <CAEDdnaXG1MFXhXDpYt97Jn0aNKZ0+Rjw8O4OFSMOXmNxiaigGg@mail.gmail.com>
 <d2cae49a-1b7d-0d18-29eb-08b58889f2a2@gmail.com>
 <CADqTB_j_BdXHPzd-fkmtSTL8ZCSR3XCgfGO+8nd_2YTkJzd+tQ@mail.gmail.com>
Message-ID: <576814CE.5060307@garfieldtech.com>
Date: Mon, 20 Jun 2016 11:07:42 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <CADqTB_j_BdXHPzd-fkmtSTL8ZCSR3XCgfGO+8nd_2YTkJzd+tQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] New escaped output operator
From: larry@garfieldtech.com (Larry Garfield)

On 06/20/2016 10:24 AM, Rasmus Schultz wrote:
>> <ul>
>> <?php foreach ( $things as $thing ) { ?>
>> <li><a href="/things/<?= $thing['name'] ?>" onclick="show_popup('<?=
>> $thing['name'] ?>');"><?= $thing['name'] ?></a>
>> <?php } ?>
>> </ul>
>>
>> There are three different escape mechanism needed there; if there is a
>> shorthand for one, do you think it will be more likely or less that people
>> will get the other two right?
> I have to agree with that - assigning special syntax to one kind of
> escape-function gives that function an elevated status, which could
> easily encourage neglect and oversight.
>
> I do wish that we had an obvious, consistently-named set of
> web-related escape/encode functions for use in plain PHP templates,
> like html(), attr(), js(), etc... having to type and read
> htmlspecialchars() and json_encode() while you're trying to visually
> parse a template is really inconvenient.
>
> That's all it is though, inconvenience. Nice to have, not must have.
>
> I'd be much more interested in a general solution to the problem of
> being unable to (or at least strongly demotivated from) using actual
> namespaced functions in this and many other cases - that's a missing
> feature and a more general problem, whereas in my opinion an operator
> or shorter function-names are just a work-around...
>
> (and please, nobody say "use a template engine" - I *am* using a
> template engine, it's called PHP!)

In many of the PHP template engines, there are multiple "filters" 
available with a specific syntax, and a way to add more.  You have to 
specify which one you want, because only you know the context.

Twig (and possibly others?) lets you set a default escaper that can be 
overridden case by case as needed, including by a "none" option.

Rather than try to make print statements themselves into a more secure 
template layer (Sorry, Rasmus, that ship has long since sailed, even 
Drupal gave up on PHPTemplate), perhaps it would be more useful to look 
at the needs of the various template engines (Twig, Smarty, Blade, etc.) 
and see what the language can/should do to make it easier for those 
engines to be made secure.  That same underlying tooling, then, can be 
exposed in a way that those still using PHP itself as a template engine 
can leverage it more easily.

I'm not 100% certain what that would look like.  My initial thought 
(which is potentially a terrible idea), is some sort of callable 
registration, akin to stream wrappers or autoloaders, where you could do 
something vaguely like this:

register_escaper('html', function($var) { return htmlentities($var, 
ENT_QUOTES | ENT_HTML5); });
register_escaper('html_attrib', function($var) { ... });
register_escaper('raw', function($var) { return $var;});

set_default_escaper('html'); // I dislike a global flag like this, but 
it works for this demonstration.

<?php
print $foo; // no escaping, because BC.
printe $foo; // Run through html escaper
printe($foo, 'html_attrib'); // Run through html_attrib escaper
?>

<?= $foo; ?> // No escaping
<?~ $foo ?> // Run through html escaper
<?~html_attrib $foo ?> // Run through html_attrib escaper

And then Twig, Smarty, etc. can also leverage the registered escapers, 
and add their own as appropriate.

That's off-the-cuff syntax that may be terrible, but the goal here is to 
better enable template engines (whether thick ones like Twig or thin 
ones like *.view.php) to do security better, rather than trying to Solve 
It For All The Things(tm), which for security is a very dangerous 
dead-end approach.

--Larry Garfield