Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94115
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <57665E36.60302@lsces.co.uk>
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>
Date: Sun, 19 Jun 2016 11:01:16 +0200
Message-ID: <CADyq6sKPDtC5Q=OV7D5qQF2W6XgJCyKXpatU0KB=StveXA8pdw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c1313f4cab66405359dd579
Subject: Re: [PHP-DEV] New escaped output operator
From: ocramius@gmail.com (Marco Pivetta)

--94eb2c1313f4cab66405359dd579
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 19 June 2016 at 10:56, Lester Caine <lester@lsces.co.uk> wrote:

> On 19/06/16 09:38, =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:
> > My point is
> > that the main job of echo operator "<?=3D ?>" is output an unknown valu=
e
> from
> > database to an HTML environment. So in all this places we should
> copy-pase
> > the call of htmlspecialchars() to prevent XSS.
>
> The majority of XSS problems are created because the free format input
> INTO the application are not correctly handled. Simply banging
> htmlspecialchars() around totally unmanaged text is NOT the solution,
> and handling the correct filtering of the inputs is where this should be
> handled.
>
> I'm sure all of you see various attempts at XSS and SQL injections in
> your log files. About 20% of my overnight traffic is people trying to
> 'get in' but because I do not allow raw text to get through all it
> results in is errors in the log files.
>
> The packages that we have had problems cleaning up have tried using the
> 'clean the output' approach, but this STILL left holes which can only be
> fixed by cleaning the input ...
>

This basically means that you lack basic understanding of how escaping and
user input are to be handled.
Most apps out there about getting a bunch of text from the user, then
rendering it somewhere else in the app.
Cleaning user input just leads to frustration and a big mess in most
scenarios, which is why we're all talking about escaping output instead.
This is not "cleaning" either, it's escaping, which is a non-destructive
and reversible operation (which is why it works so well).

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--94eb2c1313f4cab66405359dd579--