Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63071 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59141 invoked from network); 18 Sep 2012 16:56:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Sep 2012 16:56:41 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.133 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.133 smtp133.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.133] ([67.192.241.133:55464] helo=smtp133.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 78/D0-07072-8C7A8505 for ; Tue, 18 Sep 2012 12:56:40 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp13.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id F2D063D0675; Tue, 18 Sep 2012 12:56:37 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp13.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 2EE113D07C4; Tue, 18 Sep 2012 12:56:37 -0400 (EDT) Message-ID: <5058A7C4.9030903@sugarcrm.com> Date: Tue, 18 Sep 2012 09:56:36 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?P=E1draic_Brady?= CC: "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class From: smalyshev@sugarcrm.com (Stas Malyshev) 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? > 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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227