Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63106
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.186 cause and error)
Message-ID: <5058C809.50005@lsces.co.uk>
Date: Tue, 18 Sep 2012 20:14:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <CALwr1Gn4OmHP=Qa7NKzpbkq+w8FEjUMZ3v678bbZVOGM23G35g@mail.gmail.com> <5058A697.30903@sugarcrm.com> <CAAyV7nF82MW1gRpVpiVooCNyj7YE-eVDqjzqFX0m3X1J7Kp_UA@mail.gmail.com> <5058A8B8.3070404@sugarcrm.com> <5058A97A.4080900@ajf.me> <5058AABA.1040406@sugarcrm.com> <CAAyV7nHgJku5MqKY-D_Gk+DaSt-Wda3BJHsSzyS=yW6xENRi6w@mail.gmail.com> <5058B5A5.6090302@sugarcrm.com> <5058BA43.8010806@mrclay.org> <5058BBA6.4090702@sugarcrm.com> <CAAyV7nGZ2iinDUcUfsVeBxFC_2nF8TmbaDrMDQTK0dkmnLifow@mail.gmail.com>
In-Reply-To: <CAAyV7nGZ2iinDUcUfsVeBxFC_2nF8TmbaDrMDQTK0dkmnLifow@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
From: lester@lsces.co.uk (Lester Caine)

Anthony Ferrara wrote:
> Personally, I'd rather have a dedicated API. It's the only way that
> semantic meaning of the API will be preserved.
>
> In this case, I would start it as a PECL extension implementing the ESAPI
> library. Get the API right, and prove it works, then pull it into core.

Sounds the right way to placate the people who prefer this approach to building 
code. We then have the option to leave it off if we don't use it ;) I've even 
got a stock distribution that does not include any MySQL core stuff now so I'm 
happy with this modular approach.

> You can keep cramming the escaping concerns into a global filter handler
> all you want. Or we could stop, and think about designing proper APIs for a
> change. Where the API imparts both implementation and semantic meaning. An
> API where it's easy to see if a user gets it right or not.

Looking at the output 'filtering' applied to my own systems, I am more than 
happy that ACTUALLY I eliminate the problems people are quoting here, XSS 
prevention, by ensuring that the data being STORED is cleaned up in a way that I 
don't need to 'escape' anything. I do need to be able to 'encode' the output 
date to correctly display it but nothing in that process should be able to 
create an XSS problem? I do apply 'filtering' to the html tags which removes 
those that I do not want to be stored in page content, and css is similarly 
processed, so we have a run time dictionary that controls the processing rather 
than that being hard coded in the filters.

Basically if you are STORING XSS intrusions then you have badly designed code as 
there is no reason that it would be stored. If you want to 'display' suspect 
code, then it is 'escaped' before it is stored so preventing a potential problem 
if another viewer accesses the raw data!

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
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