Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16895
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=Ekaxd80TixZrg+W1vLwvvnnPUkYoDoum8HhcoJvIVFPxE+H8ySvUBi6o3tD55VkXFLyyl+jVRfQTx8LjI4QYhzKSsprkutFAvrNHtge4ss8NCCeW6oSTJXk0cTQzm4AJuXUvpTe43pZKxDkGzrpM47UUN2F5qxSzr/fSzruf4Vg=
Message-ID: <30bd8024050624122228ee41fb@mail.gmail.com>
Date: Fri, 24 Jun 2005 15:22:30 -0400
Reply-To: =?ISO-8859-1?Q?Nicolas_B=E9rard_Nault?= <nicobn@gmail.com>
To: DvDmanDT <dvdmandt@telia.com>
Cc: internals@lists.php.net
In-Reply-To: <04.19.22648.2895CB24@pb1.pair.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <20050624055017.25065.qmail@desk.crynwr.com>
	<04.19.22648.2895CB24@pb1.pair.com>
Subject: Re: [PHP-DEV] Re: 'include' Considered Harmful
From: nicobn@gmail.com (=?ISO-8859-1?Q?Nicolas_B=E9rard_Nault?=)

This has been discussed very much long ago. I use variables in include
clauses and always take a very special attention at it. Adding a
warning in E_STRICT does not make any sense either. In no way PHP can
judge if the instruction is needed or not. I, for myself, code in
E_STRICT and don't deserve any supplementary warnings. Correctly using
the include clause is the programmer's responsability.

Keep one thing in mind: PHP is not a babysitter.

On 6/24/05, DvDmanDT <dvdmandt@telia.com> wrote:
> Hmm.. If anything, E_STRICT could leave a warning about variables being u=
sed
> with include/require.. This is the PHP programmers fault clearly.. And th=
e
> documentation is exactly the right place.. Your suggestion is pretty much=
 as
> stupid as suggesting to forbid ../ in fopen().. There's nothing wrong wit=
h
> PHP, it's definitly the PHP programmers fault.. It does exactly what I
> expect it to do, and afaik, what most people expect it to do.. If they wr=
ite
> code to include unchecked GET/POST vars, then they don't write code with
> security in mind at all..
>=20
>=20
> <nelson-lists@crynwr.com> skrev i meddelandet
> news:20050624055017.25065.qmail@desk.crynwr.com...
> >I believe that the 'include' operator is intrinsically harmful.  As
> > evidence I introduce three exhibits: Google for "php security flaw".
> > The very first page you find will explain how a very common use of
> > 'include' is insecure.  As the second bit of evidence, I introduce the
> > fact both of the naive php programmers working on my server introduced
> > this security flaw in separate web pages.  As the third bit of
> > evidence, I point out that crackers have created security tools
> > designed specifically to exploit this flaw.
> >
> > This security flaw is common.
> >
> > I'm aware that it's possible to write php code that uses the current
> > include securely manner.  I'm aware that it's possible to turn off
> > this functionality.  I'm aware that it's possible to run php in a more
> > secure manner.
> >
> > The evidence presented above says that none of those possibilities are
> > pursued often enough.  It's possible that they could be encouraged
> > more.  I suggest instead that 'include' as designed is intrinsically
> > harmful.  It's an attractive nuisance.
> >
> > I suggest that its functionality should be split into two operators.
> > One of these operators is still called 'include' and behaves the way
> > that naive PHP programmers believe it behaves: it only includes files
> > taken from the local file system.  It doesn't include any files with
> > two consecutive dots, and it doesn't include any file beginning with
> > slash.  In other words, it can only be used to include files at or
> > below the current directory.
> >
> > Another operator (which I would call 'includeremotesecurityhole', but
> > you can call it what you will) behaves the way the current php
> > operator behaves.  If so instructed, it will fetch remote hostile
> > content and execute it with local privileges.
> >
> > FAQs:
> >
> > Q: Are you stupid?
> > A: Not particularly.  Stupidity and ignorance are not the same thing.
> >
> > Q: If you're that ignorant, you got what you deserve.
> > A: Actually, there are many things of which I'm ignorant, and I
> >   deserve no harm from any of the other things.
> >
> > Q: Why did you allow these programmers to write such code?
> > A: Because I thought PHP didn't have such huge gaping security flaws.
> >
> > Q: PHP doesn't have those flaws; the programmers put it in.
> > A: If that's the case, then why do so many programmers put it in?
> >
> > Q: All other systems have the same problems: .ASP, .NET, etc.
> > A: And those are quality targets to shoot for?
> >
> > Q: Do you hate PHP?
> > A: No, I love PHP!  It allows naive programmers to be amazingly
> >   productive.
> >
> > Q: If you hate PHP so much, just turn it off.
> > A: But PHP allows naive programmers to be amazingly productive.
> >
> > Q: Did you read the documentation?  It clearly explains the risks.
> > A: The documentation is the wrong place to fix this problem.
> >
> > Q: Did you turn off the remote-fetching, local-executing feature?
> > A: The configuration is the wrong place to fix this problem.
> >
> > Q: 'include' works just fine; why do you want to change it?
> > A: Because it creates the wrong expectation in programmers new to
> >   PHP.  If the operator had the same semantics but the name
> >   'includeremotesecurityhole' programmers would change their
> >   expectations of the operator.  Hazardous equipment will have yellow
> >   markings on it precisely because the equipment doesn't look
> >   dangerous.  A saw blade doesn't need yellow markings because it
> >   *is* what it appears to be: extremely sharp and dangerous.
> >
> > Q: Do you know how much code this change will break?
> > A: No.  Do you know how much insecure code is out there waiting to be
> >   found and exploited, which this change will make secure?
> >
> > --
> > --My blog is at     blog.russnelson.com         | If you want to find
> > Crynwr sells support for free software  | PGPok | injustice in economic
> > 521 Pleasant Valley Rd. | +1 315-323-1241       | affairs, look for the
> > Potsdam, NY 13676-3213  |                       | hand of a legislator.
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20
>=20


--=20
Nicolas B=E9rard Nault (nicobn@gmail.com)
"Maybe nature is fundamentally ugly, chaotic and complicated. But if
it's like that, then I want out." -- Steven Weinberg (prix Nobel de
physique, 1979).