Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82002 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43140 invoked from network); 6 Feb 2015 03:41:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Feb 2015 03:41:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.54 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.216.54 mail-qa0-f54.google.com Received: from [209.85.216.54] ([209.85.216.54:59701] helo=mail-qa0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9B/1C-17766-AC734D45 for ; Thu, 05 Feb 2015 22:40:59 -0500 Received: by mail-qa0-f54.google.com with SMTP id w8so9082467qac.13 for ; Thu, 05 Feb 2015 19:40:55 -0800 (PST) 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; bh=SImuZ18fmxaJph/YbHUXSI+45fTnUnzrjz/FkOB1BwQ=; b=JOWEayoHDSRIhhd0Lt9F+BlIEJtikWPPeyEGjqU37gFympb46sx1gaE0FWOOsT3ciX 6A7n4v5a6xVsrb89e9Qx5ZW+Juu5C7ODIK8h21XlTBp3MDHTwU7jZzdu8wP3llBB2yPX AmwVVg32/pziu7Z5iwq/jQGwtOmhLjwksfkkJuGkxfWw5HJZimVhyja6tlGfvDqBe8c6 hWPiwT7MUZj34hYSjUqlIIkTg01ivSQsFkD71hM0/AyHau/OZA9tyNv59ssZ6QeTUes5 k+F6nCKkV2dAHbBCLeNOzBYDIHv3v4Sypi2K0JaNlto5wKHvW/ZhH+km7InYNOuObATR cd0A== MIME-Version: 1.0 X-Received: by 10.224.21.72 with SMTP id i8mr799556qab.17.1423194055564; Thu, 05 Feb 2015 19:40:55 -0800 (PST) Received: by 10.96.3.168 with HTTP; Thu, 5 Feb 2015 19:40:55 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Feb 2015 10:40:55 +0700 Message-ID: To: Yasuo Ohgaki Cc: Adam Harvey , PHP internals , Leigh , reeze Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once() From: pierre.php@gmail.com (Pierre Joye) On Fri, Feb 6, 2015 at 10:33 AM, Yasuo Ohgaki wrote: > Hi Pierre, > > On Fri, Feb 6, 2015 at 11:13 AM, Pierre Joye wrote: >> >> > I am :) Almost all of my clients are ISMS or similar certified. >> >> Marketing ;) >> >> >> However, back to this exact feature. I am not convinced it is the >> >> right way, there are many cases required more than just checking valid >> >> code (> >> archives-like solutions. And even with this solution, a compromised >> >> server (via a web app or other) could still do whatever they want with >> >> php scripts if the web server is not configured correctly. >> > >> > >> > With this proposal, > >> So phar won't work with require_script? If that's the case then it does >> look good to me. > > Good point! I'll add this to the RFC. > I'm not too familiar to phar format. > > Uncompressed phar has .php. > Compressed phar can be syntax error. I need to consider more including byte > compilers. > >> > For example, one of the easiest way to take over servers is embed >> > script into session data files. This is prevented effectively. >> > >> > Users who allows phar/etc file uploads, they may have encryption or >> > compression as mitigation. >> >> What does it have to do with upload? >> >> Uploads are and should not be in a folder where php can be executed. This >> is a basic configuration issue on almost all web servers. > > I agree that files are better/should be located other than web root. > Many apps only checks extension stores anything under web root. > > Even if uploaded files are stored under non web root dir, attackers can use > path > traversal or even full path with bad code. As long as PHP can access, > attacker > can access to files for inclusion attacks. Compression/encryption prevents > attack files executing via script()/require(). Does this answer to you? Not really. One will have to use exec and call php and the desired file as a well configured server won't allow exec of php in the upload or tmp dir, via the web server. It does not mean they are outside a web doc root, only that no php (or other) will ever be executed from there. Also PHP is one part of the big picture, so I will simply summarize it as "as long as one can access" instead of "as long as PHP can access". That says all we need to know about emulating (badly anyway) OS security features in PHP. > I realized that I didn't think of byte compiler format. I have to research > it. > IIRC, Zend allows to have custom script loader. > Could anyone give some pointers to look around? or give some ideas? PHK and Phar f.e. -- Pierre @pierrejoye | http://www.libgd.org