Yasuo Ohgaki wrote (on 13/02/2014):
But if somebody is using include() for non-PHP data, they're using
the wrong function anyway, end of story.
Right. This is what I would like to change.
In other languages, such script inclusion ends up syntax error, end of attack.
I was talking here about my cases 3 and 4, where the author is *deliberately* using include for something other than code. There is already a correct function for that, which is readfile(), or more likely file_get_contents() and then some processing, so no changes are needed to introduce it.
There are number of ways to inject piece of PHP code into files. Attacker can exploit other feature/vulnerability to take over server completely. Session file is one of the common method.
Are session files relevant to this discussion, or was this just a side note?
Compile error will not display any code/contents except a piece displayed as error message.
That's not quite true. A fatal error can occur after output has been flushed through to the browser. The include statement will succeed (acting like readfile()), and the fatal error, if any, will happen afterwards, e.g. because an expected class definition was not loaded.
Take a look at vulnerability reports, you'll find number of LFI that could be prevented by this RFC.
I looked at some of the examples in the RFC, but I don't understand how they relate to this proposal. No amount of links to vulnerability reports can tell me that, but you can.
What I am asking for is an example - real or artificial, I don't mind - with an explanation of how it behaves now, and how that behaviour would be improved by the proposed change.
Note that I'm not trying to shoot down your proposal - on the contrary, I'm trying to make sure its benefits are clearer, so that people will have a better means of judging it.
Regards,
--
Rowan Collins
[IMSoP]