E_STRICT would be a nice place to leave a warning, but of course, the naive programmers don't use E_STRICT, so what's the point in that? Personally, I think include is just fine the way it is. What I could imagine though, is that the include() function would be enhanced with parameters to allow/disallow the inclusion of remote files and files in parent dirs... but I don't see the point, and it would suddenly create an unwanted difference between the include construct and the include function...
Nah, if it were up to me, we'd leave include just the way it is.... Ron ""DvDmanDT"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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
