Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63103 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23731 invoked from network); 18 Sep 2012 18:54:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Sep 2012 18:54:55 -0000 Authentication-Results: pb1.pair.com smtp.mail=padraic.brady@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=padraic.brady@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.42 as permitted sender) X-PHP-List-Original-Sender: padraic.brady@gmail.com X-Host-Fingerprint: 209.85.219.42 mail-oa0-f42.google.com Received: from [209.85.219.42] ([209.85.219.42:40312] helo=mail-oa0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0A/3F-07072-F73C8505 for ; Tue, 18 Sep 2012 14:54:55 -0400 Received: by oagh2 with SMTP id h2so235164oag.29 for ; Tue, 18 Sep 2012 11:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vtOYSG/9JHOVY9oI3b63cbcwc5rIJqMMsZ6V8HUi0Q8=; b=e9XCWDWYd86edXUDLRFZmpzYhyLTUCrAhw3AePjvZDpBlRWUOGxgdCIDGz6uYzT6pl E59KwEixOu7MFWn71FEOZ1qLViypJoye79L0Mycn5w515M4B+78Up7bfYF4NND9y8Ymu KwoeIOr+L6RAdS8y4zCB6ezUKhaTc8vqc0OZuh73rxZe2LQjqY3M8v9V1+UazOoLwk/5 OLPwKCHQ3OUiQD3p4G4sWgzqWE53UYz3QiCewvmlKtDuVQD9j2EBkhuUpi68z13wExCT da2RrddCrFGWp3feO8qlY304vnq5YM2HG+NzZTzlrnrif2Ag0XHe37YeAyksWoIg8FhK qfXQ== MIME-Version: 1.0 Received: by 10.60.20.165 with SMTP id o5mr1022501oee.135.1347994492780; Tue, 18 Sep 2012 11:54:52 -0700 (PDT) Received: by 10.76.7.84 with HTTP; Tue, 18 Sep 2012 11:54:52 -0700 (PDT) In-Reply-To: <5058BB3B.1050300@sugarcrm.com> References: <5058A7C4.9030903@sugarcrm.com> <5058BB3B.1050300@sugarcrm.com> Date: Tue, 18 Sep 2012 19:54:52 +0100 Message-ID: To: Stas Malyshev Cc: "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?=) On Tue, Sep 18, 2012 at 7:19 PM, Stas Malyshev wro= te: > 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. The libraries and the frameworks are wrong. I'm serious too. Try finding just one that does Javascript escaping properly (if at all). >> 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. Links? Last I checked, no, we don't already have functions for all of this. And those that do exist have insecure behaviour - I did link to the relevant article on htmlspecialchars() which details that with examples you can download from Github. >> 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. The fact is that people neither know how to implement these safely AND do not know when and where to use them in their correct combinations. Security related code needs a lot of peer review. It's beyond the scope of the average programmer, barely within the scope of large frameworks but should be perfectly within PHP's scope to manage and have some level of confidence in its security while doing us all a favour by addressing a significant security risk in PHP applications. Paddy --=20 P=E1draic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team