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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to