Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:81996 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30500 invoked from network); 6 Feb 2015 01:39:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Feb 2015 01:39:12 -0000 Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.51 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.216.51 mail-qa0-f51.google.com Received: from [209.85.216.51] ([209.85.216.51:54062] helo=mail-qa0-f51.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0F/E9-17766-D3B14D45 for ; Thu, 05 Feb 2015 20:39:11 -0500 Received: by mail-qa0-f51.google.com with SMTP id f12so8698361qad.10 for ; Thu, 05 Feb 2015 17:39:06 -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=tMkT/SgLAsYoN+J28zHgQc4ALOuKjb2DYIV2TZ2OkJU=; b=LoHsRCzqYFOJHK8uVmYlAQtst2nHImAoQnUj5kTqOlh3+KPZYnhXlSfZ3hG9aqSIQ4 S9wXWsUMqrgzM1sEODToto+EVO0T57yTjqYviUzrlECQH/8fH2T1IjYBEjWQ9omsV3Gn N9AWmL/6WIJmHsBedLcNKAdvmnTPasr3/oximYRwPjbztvuky5kcprYQrBQEWD/F6/mH Y+1PuShYkki3JrfZjAftAUyn3KfAVcY88UZ03vB73s3wYt4ZqSmVTXIXSlI6em59JLPa sA2DQaJZV2YXEORvKrvRInNfNf8IvV4J7Yggr3Po9WNVEbGhqBh/MbZXJ+CQjHDRqit7 BVgg== MIME-Version: 1.0 X-Received: by 10.140.39.84 with SMTP id u78mr2509737qgu.63.1423186746605; Thu, 05 Feb 2015 17:39:06 -0800 (PST) Received: by 10.96.3.168 with HTTP; Thu, 5 Feb 2015 17:39:06 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Feb 2015 08:39:06 +0700 Message-ID: To: Yasuo Ohgaki Cc: Leigh , Adam Harvey , reeze , "internals@lists.php.net" 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 8:25 AM, Yasuo Ohgaki wrote: > Hi Pierre, > > On Thu, Feb 5, 2015 at 8:49 PM, Pierre Joye wrote: >> >> PHP is just as safe than the other languages. PHP applicatons maybe >> less, maybe more. I tend to see the amount of attacks as a proof of >> success of a tool instead of a proof of the tool being unsafe (not >> worth attacking 0.01% of the market when you can attack 75%). >> >> > Your proposal requires admins to do the job. It's better to have >> > developer >> > option. >> > >> > Do any of you have other preferred option for developers? >> >> We do have one, it is called open_basedir, which I wanted to remove as >> well but we agreed that it has its usefulness. One of them being >> exactly to avoid the inclusion (and display) of critical information. >> It indeed does not prevent one to include and display some text data >> containing passwords or the likes when they are in the open_basedir >> list but still. >> >> And again, if one app allows unvalidated include/require (as in your >> example), it will most likely do fopen and co as well and get data >> displayed one way or another. Using yet another construct will again >> give a false sense of security, solving a real problem using a bandaid >> tape. > > > I agree that user must be careful for any file function. This is not limited > to > include/require. > > PHP is unique compare to other languages. PHP allows "script include > statements" > to open files as "script embedded file". > > The result is completely different. > > - PHP file exposure and script execution > - Others syntax error mostly > > PHP == Fatal security issue, Others == Bug. > > AFAIK, Ruby/Perl allows script execution with simple file validation. e.g. > Inject code after GIF file signature. However, Ruby/Perl apps were not > reported as vulnerable > to script inclusion because usual image check, e.g. check image size, can > prevent > attack image to be stored. Any other files are failed as syntax errors. > > In contrast, PHP allows to embed script anywhere in a file. Image size check > does not > help at all. Converting size does not help also. (e.g. Attacker may embed > script in > color table. Changing size/recreating image cannot prevent attacks) If data > is written > into files, it can be used to execute. *Session data* file can be used to > attack, too. > These are the reason why file inclusion attacks against PHP applications > are so > popular/common. > > Any PHP applications do file upload (image/etc) or data file writes > (wiki/session data) have > much higher script inclusion risk compare to others. > > Other languages have fopen/readfile also. In this case, the result is the > same. > PHP is as safe as other languages in this area. > > PHP has became as secure as other languages _except_ script inclusion which > allows attackers take over servers. This is what I would like to change. > > We have been removed embedded script from regex, i.e > preg_relace/mb_ereg_replace, > because it is dangerous. Why don't we remove embedded script from > include/require. > include/require is used to execute attack script more often than regex. PHP7 > seems > perfect opportunity to me. > > Feasible options are > - Introduce script only inclusion statement. script()/script_once() > - Change require()/require_once() behavior not to embed script. > > Let's have no more script/file inclusion attacks! > > > Regards, > > P.S. Changing the result of bugs like this is defined as a security measure > by ISO 27000. I do not put high value in this ISO ;-) 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 (