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
