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 <[EMAIL PROTECTED]> wrote: > 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.. > > > <[EMAIL PROTECTED]> skrev i meddelandet > news:[EMAIL PROTECTED] > >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 > > -- Nicolas Bérard Nault ([EMAIL PROTECTED]) "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). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
