Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16894
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <04.19.22648.2895CB24@pb1.pair.com>
To: internals@lists.php.net
References: <20050624055017.25065.qmail@desk.crynwr.com>
Date: Fri, 24 Jun 2005 21:02:29 +0200
Lines: 97
Subject: Re: 'include' Considered Harmful
From: dvdmandt@telia.com ("DvDmanDT")

Hmm.. If anything, E_STRICT could leave a warning about variables being used 
with include/require.. This is the PHP programmers fault clearly.. And the 
documentation is exactly the right place.. Your suggestion is pretty much as 
stupid as suggesting to forbid ../ in fopen().. There's nothing wrong with 
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 write 
code to include unchecked GET/POST vars, then they don't write code with 
security in mind at all..


<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.