Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94142
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.220.181 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <CAMPTd_A6YzDDenDp+twULMPRbKRhw408m=XifiRWnC=RG4dxHw@mail.gmail.com>
References: <CAEDdnaX_KbaZB=3WzFAp73E0dCxx5zuoqMbPbakMUGpHyRPJFg@mail.gmail.com>
 <b9318b90-f850-12a2-459d-8995220922df@gmail.com> <20160617202344.2868F1A80C02@dd1730.kasserver.com>
 <CAObuZdvZoACWE1bxz2PUMW+yXHxyEtXuYpPXL=6dEqrsakSNBQ@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> <CAMPTd_A6YzDDenDp+twULMPRbKRhw408m=XifiRWnC=RG4dxHw@mail.gmail.com>
Date: Sun, 19 Jun 2016 20:39:59 -0700
Message-ID: <CANaX5ndUCfFOUCdveCxUZN62HYa0VeHi6c1Zj7omDUgoXmrUwg@mail.gmail.com>
To: Walter Parker <walterp@gmail.com>
Cc: =?UTF-8?B?0JzQuNGF0LDQuNC7INCS0L7RgdGC0YDQuNC60L7Qsg==?= <michael.vostrikov@gmail.com>, 
	Scott Arciszewski <scott@paragonie.com>, Lester Caine <lester@lsces.co.uk>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114aabcc7799420535ad752a
Subject: Re: [PHP-DEV] New escaped output operator
From: davey@php.net (Davey Shafik)

--001a114aabcc7799420535ad752a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 19, 2016 at 8:30 PM, Walter Parker <walterp@gmail.com> wrote:

> Good, then we do agree, as what I said was what I DID NOT want to see in
> the documentation.
>
> This should be documented as shortcut for <? echo htmlspecialchars(string=
)
> ?>. It should be further pointed out that while this will be useful in
> catching many XSS and other HTML issues, it will not catch all of them, s=
o
> care and attention to proper data hygiene is still required.
>
>
> Walter
>
> On Sun, Jun 19, 2016 at 8:22 PM, =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=
=92=D0=BE=D1=81=D1=82=D1=80=D0=B8=D0=BA=D0=BE=D0=B2 <
> michael.vostrikov@gmail.com> wrote:
>
> > > "Use '<?~' and it will solve your XSS and other escaping problems wit=
h
> > outputting HTML that was stored in a DB."
> > I don't think this is a good phrase for documentation. This form should
> be
> > considered exactly as htmlspecialchars, with taking into account any
> > language and encoding-specific issues, and this should be pointed in
> > documentation. This is a shorcut for often operation, like '??' for
> isset()
> > check. And it can really improve security, not in 90% but about 99.9999=
%
> > cases.
> >
> > 2016-06-20 4:41 GMT+05:00 Walter Parker <walterp@gmail.com>:
> >
> >>
> >>>
> >>> > where getting it 90% correct is worse that not doing anything at al=
l.
> >>> > Things like this will cause people to be blindsided when the uncaug=
ht
> >>> escapes
> >>> > cause the next major security problem.
> >>>
> >>> Why do you think so? What real problems can happen if there will be a
> >>> short operator for htmlspecialchars()?
> >>>
> >>> What could happen is this getting sold/documented as a general purpos=
e
> >> security feature:
> >> "Use '<?~' and it will solve your XSS and other escaping problems with
> >> outputting HTML that was stored in a DB."  What it solves is a subset,
> >> which is escaping characters stored in a data that have special
> meanings to
> >> HTML. My concern is that the remain security issues might get
> overlooked or
> >> ignored because '<?~' is considered good enough. There are issues with
> >> htmlspecialchars, UTF-8 and certain language-specific characters (non
> >> English). There were also issues with quotes in the past.
> >>
>

There will never be a way to make this operator useful to a majority of
users or use cases; similar ideas have been discussed many times in the
past.

If we get annotations then you might be able to hook something in from
userland transparently that understands your specific context and
application. This would be much more feasible IMO.

- Davey

--001a114aabcc7799420535ad752a--