Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63088
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5058A7C4.9030903@sugarcrm.com>
References: <CALwr1Gn4OmHP=Qa7NKzpbkq+w8FEjUMZ3v678bbZVOGM23G35g@mail.gmail.com>
	<alpine.DEB.2.02.1209180809010.28929@whisky.home.derickrethans.nl>
	<CALwr1GnjwyE=yipK6UNkOm9m31LDDbpbcdgmr_nf0cUo+zOedw@mail.gmail.com>
	<CALwr1G=DOKmjudFFEAFY+6hmUh3q+qNe1ntWY1FLXP5GChLZdA@mail.gmail.com>
	<5058A7C4.9030903@sugarcrm.com>
Date: Tue, 18 Sep 2012 18:57:36 +0100
Message-ID: <CALwr1Gm3aZq0cv52qmVpC7aXd+dJw9-f21P6wvn9ZPu4P4d1zA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
From: padraic.brady@gmail.com (=?ISO-8859-1?Q?P=E1draic_Brady?=)

Hi Stas,

On Tue, Sep 18, 2012 at 5:56 PM, Stas Malyshev <smalyshev@sugarcrm.com> wro=
te:
> Hi!
>
>> The point of the RFC is to ensure a consistent API for escaping is
>> available to all PHP programmers without resorting to userland
>
> I do not see why "without resorting to userland" is a worthy goal in
> every case. It's like saying "I want to code in Python without ever
> using import" or "I want to code in Perl without ever using CPAN". Makes
> no sense, right? Why we should insist on this in PHP?

Programmers haven't figured out how to use the 1-2 covering functions
that already exist and you expect them to do it in userland code?
Maybe we should ditch json_encode() tomorrow. I can do it in userland
code too. PHP does a LOT of things possible in userland code. The
argument I made in the RFC boils down to simply giving programmers a
helping hand. They are writing insecure code because PHP isn't
fulfilling that need for one of the most serious security risks in PHP
today. Surely that warrants action to serve programmers?

>> solutions. Existing functions are widely misused, misconfigured or
>> have builtin security issues yet are popularly advanced as "escaping"
>> for XSS.
>
> Do you think your functions won't be misused, misconfigured and never
> would have bugs? Exactly the same would happen. Having yet another API
> doing the same as old API is not a solution.

They have one configuration value. All other behaviour is fixed. How
is this remotely similar to the "old API"? Misuse can be constrained
to calling the wrong function and setting the wrong character
encoding. That's 2 versus the list of flaws in htmlspecialchars() I
blogged about (the link is in the RFC) and whatever might
theoretically exist if PHP actually had Javascript and CSS options.

> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227



--=20
P=E1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team