Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94144
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.160 cause and error)
MIME-Version: 1.0
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> <5766FA91.60803@lsces.co.uk>
In-Reply-To: <5766FA91.60803@lsces.co.uk>
Date: Mon, 20 Jun 2016 06:00:26 +0000
Message-ID: <CANUQDCis9TVyR6fNbDOfCWF1fJeqU0M+Gby-_C47pEXZocBang@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=089e0122ebe26f15c80535af6cfa
Subject: Re: [PHP-DEV] New escaped output operator
From: me@kelunik.com (Niklas Keller)

--089e0122ebe26f15c80535af6cfa
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Lester Caine <lester@lsces.co.uk> schrieb am So., 19. Juni 2016, 22:03:

> On 19/06/16 19:33, =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 wrote:
> > Lester
> >
> >> > there is NO need to simply slap htmlspecialchars() onto
> >> > properly built data
> > There are many cases when user data can contain quotes or other html
> > entities.
> >
> > <img title=3D"<?=3D $book['title'] ?>" />
> > // $book['title'] =3D 'When we say "Hello"';
> >
> > <div><?=3D $user['about_me'] ?></div>
> > // $user['about_me'] =3D 'I am a programmer. I like to write
> > <script>alert("xss")</script> in "About me" field';
>
> ( Cut moan about top posting and duplicating sigs and I use plain text
> for any email archive )
>
> Now ... I want to add content that includes
> <script>alert("xss")</script> it needs to be in the format
> &lt;script&gt;alert(&quot;xss&quot;)&lt;script&gt; so that it never
> appears in the 'dangerous' format, but if $user['about_me'] is
> designated a simple text string, then any attempt to add
> <script>alert("xss")</script> via an input should be blocked!


No, it shouldn't be blocked. It should just be escaped on output. What if
that's a comment to a tech blog, where we talk about these things instead
of trying to find a vulnerability?

The input

processing of text needs to understand what it is expecting to receive
> and process it accordingly, so if the content is material such as email
> messages it can be correctly processed for storage by escaping if
> necessary. The fun comes when you are looking for content such as "About
> me" AFTER the data has been sanitised. In this case the search term
> needs to be processed as well so &quot;About me&quot; ...


One more reason not to escape on input.

so again one
> needs to know just what state the data is in and my input process
> converts ' to &#39; as well to be safe when using single quotes.
>

What if you suddenly start to output it in JSON or plain text format?
Suddenly you need a different escaping.

You really shouldn't escape on input, as your input doesn't know where it's
used.

What you should do on input is validation, so decide whether it's in the
right format. But if it doesn't validate, you reject it and don't even save
it.

Of cause there are very good reasons why messages and comments should be
> limited to simple text. Many Wordpress/Joomla/etc problems would have
> been prevented if the trend to use HTML for everything had not started.
> Strip any tags and just leave the raw text is ideal for comment fields
> which can be the target for scammers where uncontrolled access may be
> required. And if there is a limit on field size in the database, the
> same restriction should apply to the data entry ... If the data is
> expanded by the sanitising process that also needs to be taken into
> account, along with multi byte characters.
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=3Dcontact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e0122ebe26f15c80535af6cfa--