On Thu, Feb 5, 2015 at 5:47 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi Pierre and all, > > On Thu, Feb 5, 2015 at 7:24 PM, Pierre Joye <pierre....@gmail.com> wrote: >> >> > >> > >> > I'm proposing *SCRIPT* only inclusion. This can be done by >> > >> > - allowing "<?php" only at to top of script >> > - not allowing "?>" anywhere (We may allow at the end possibly) >> > >> > Those who do not understand my point. >> > Please search by "PHP LFI" or "PHP file inclusion" for real life >> > security issues. >> >> I do understand what you try to achieve, from all point of view. >> However I strongly disagree with this as a security improvement. I see >> this more as yet another attempt to replace what should be done at the >> OS level. > > > This is "PHP inclusion" search result. > > http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=PHP&filter_exploit_text=inclusion&filter_author=&filter_platform=0&filter_type=0&filter_lang_id=0&filter_port=&filter_osvdb=&filter_cve= > > While I understand your opinion and the methodology is good practice indeed, > but I > cannot ignore the fact that PHP is *MUCH* more vulnerable than other > languages. Other > languages do not have many security issue like PHP. The reason is simple. > > PHP enables embedding mode always for script inclusion. > > Solution is simple also. > > Provide non embedding mode script inclusion. > > PHP is made for web and web is priority target of attackers. > PHP is better to be safer than now, the same level as other languages at > least. > > I hope there will be a consensus to make PHP safer as other languages.
PHP is just as safe than the other languages. PHP applicatons maybe less, maybe more. I tend to see the amount of attacks as a proof of success of a tool instead of a proof of the tool being unsafe (not worth attacking 0.01% of the market when you can attack 75%). > Your proposal requires admins to do the job. It's better to have developer > option. > > Do any of you have other preferred option for developers? We do have one, it is called open_basedir, which I wanted to remove as well but we agreed that it has its usefulness. One of them being exactly to avoid the inclusion (and display) of critical information. It indeed does not prevent one to include and display some text data containing passwords or the likes when they are in the open_basedir list but still. And again, if one app allows unvalidated include/require (as in your example), it will most likely do fopen and co as well and get data displayed one way or another. Using yet another construct will again give a false sense of security, solving a real problem using a bandaid tape. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
