Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63094 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5873 invoked from network); 18 Sep 2012 18:19:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Sep 2012 18:19:45 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; 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:32835] helo=smtp133.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 93/3B-07072-F3BB8505 for ; Tue, 18 Sep 2012 14:19:43 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp13.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id BC9633D04C2; Tue, 18 Sep 2012 14:19:40 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp13.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 671993D06F4; Tue, 18 Sep 2012 14:19:40 -0400 (EDT) Message-ID: <5058BB3B.1050300@sugarcrm.com> Date: Tue, 18 Sep 2012 11:19:39 -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: <5058A7C4.9030903@sugarcrm.com> 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! > 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? I expect them to use libraries. I don't think anything that is written in PHP means it's wrong and has to be rewritten in C. > 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? We already have basic functions that do that, and we have extension that does that. If you need more, I'm not sure you should do it in C. If you do just the same under a different name, I don't think it should be done at all. > 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. I think the approach of creating third data filtering API (plain functions, filter, and now this) in PHP core is wrong. I do not see why the same functions can not be (in case of CSS) or already are not (in case of most others) implemented in existing functionality. If the whole question is that people don't know which one to use in which context, creating an entirely new core API does not sound like a good solution to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227