On Sat, May 19, 2007 4:42 am, Cristian Rodriguez wrote: >>2007/5/18, Stanislav Malyshev <[EMAIL PROTECTED]>: >> Sane hosters do not rely on general-purpose language to provide >> security, they use OS and hardware designed for exactly that >> purpose. ;) > > unfortunately hosters has to equilibrate security vs/usability for > their customers.. so disaloowing 100% access to outside world is > frecuently not possible. > > The issue with this remote url include thingy is that is hard to find > a valid use case ..does anyone has a **real** one ? why it was > introduced in the first place..?? no, Im not talking about crippling > the language for security reasons as some may argue..my point is this > "feature" in the reality causes far more harm than good and it has > become one of the top ways to attack applications since it's > introduction..my intention is only to make people think if the hassle > of adding new ini directives (like allow_url_include) or functions is > worth. maybe with PHP6 this issue can be addressed from it's roots > instead of adding yet another workaround.
The main problem, I think, is that you are looking at allow_url_fopen as a "Feature" somebody added, rather than as a side-effect of having the base common code of include and fopen both working through the same low-level functions. Remote URL 'include' mostly "works" because it basically just calls the C-equivalent of eval(file_get_contents()) -- the guts of include and the guts of the basic file-reading code are the same code... So it's either: A) Re-write include from scratch to not use the same basic file-reading functions as the rest of PHP uses. B) Hack a black-list approach to disallow include() to use "remote" files. Unfortunately, A) is a ton more work than B), even if everybody recognizes that B) is not necessarily the "best" answer. And, in fact, B) is now having some false-positive (false-negative?) side-effects of disallowing things like 'phar' from working, even though it should work. This is not a trivial "change one line of code" fix. It's endemic to include and stream functionality, and there are pros and cons to the various solutions being batted around. I suspect that there *are* valid uses of remote include, and have posted a couple (admittedly somewhat lame ones) already. I'm suspect people who actually USE the feature have more realistic needs... But perhaps not. Even if nobody in the world *needs* the feature, and could re-code their application to not use it, there are a lot of scripts that use it, some more wisely than others... But it seems like people are so polarized on this topic, and their own views are so ingrained, that nobody is even willing to recognize that other positions are valid, so we have an endless parade of "only my answer is correct" here. That is not effective communication, nor useful discourse, imho. [insert Monty Python argument skit here] Of course, suggestions with actual PATCHES to "fix" the problem in whatever way the poster sees fit, and a shoot-out of testing those for vulnerabilities and usablity would be most welcome. :-) -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
