Yasuo Ohgaki wrote:
Does this answer to you?
I'll reorganize the RFC from now.
I'll refer you agin to https://wiki.php.net/rfc/source_files_without_opening_tag which was cloulding my own reading of the new rfc! Tom's first paragraph is the pertinent bit ...
In the past I did my best work while sleeping. Gather all the facts and go to bed ... invariably I'd wake up as I have now in the early hours of the morning with an answer. Problem these days is simply remembering enough information to work with. As we get older the 20+ years old stuff remains stubbornly stable and we forget the new stuff! That is why as you get older you will start objecting to unnecessary change ... I still hit <Ctrl><C> for copy even where the 'new' version is <Shift><Ins> :( But as usual I'm digressing ... old age.
RFI is as far as I an tell simply a matter of of configuring the web server to only process .php files via PHP ? If you are allowing users to upload .PHP files onto your machine in a location they can then run them you have bigger problems than PHP.
LFI is the one that will allow corrupted files containing .php tags to run if you have not taken care of them while they are being uploaded. ONLY permanently disabling embedding will guarantee that these files do not get accidentally loaded. i.e. 'changes the spirit of PHP too much' ...
----
function render_template($template, $template_vars) {
ini_set('template_mode', 'on'); // Older PHP ignores
include($template, $template_vars); // Or use any other method to render.
ini_set('template_mode', 'off'); // Older PHP ignores
}
----
Simply pushes the problem around a little and still requires that '$template' does not point at a file that contains embedded nasties?
include($template.'.php', $template_vars); does the job a lot easier?
Modern frameworks ... if they are well designed ... should already have addressed all of the holes that could allow tainted files to be accessed. Embedding is the essence of PHP and for many users adding a few lines of PHP to an essentially html document is all that is needed. They don't need the ton of framework code?
Smarty dropped embedded PHP from their templates in S3 'because of the security risk' but all it actually did was required that the problem php code in S2 scripts was moved back into the calling PHP. It lost a LOT of flexibility and passed the buck rather than fixing the problem. It did not fix the risk at all. I don't see how this is doing any more than pushing the problem around? You still need to properly sanitise the material and if people want to do stupid things like
ini_set('template_mode', 'on'); // Older PHP ignores
include($_GET['template']); // Or use any other method to render.
ini_set('template_mode', 'off'); // Older PHP ignores
can you really protect them anyway? Anybody who codes like that when the problems are so well advertised can't be protected except by turning off 'PHP'.
I'm sure many newer users would be better off simply ignoring embedded html altogether. It would make there code a lot more secure and would remove the need for tags, but is that then PHP?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk