Re: Re: [RFC][DISCUSSION] script() and script_once()

On Fri, Feb 6, 2015 at 8:25 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi Pierre, > > On Thu, Feb 5, 2015 at 8:49 PM, Pierre Joye <pierre.php@gmail.com> wrote: >> >> 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. > > > I agree that user must be careful for any file function. This is not limited > to > include/require. > > PHP is unique compare to other languages. PHP allows "script include > statements" > to open files as "script embedded file". > > The result is completely different. > > - PHP file exposure and script execution > - Others syntax error mostly > > PHP == Fatal security issue, Others == Bug. > > AFAIK, Ruby/Perl allows script execution with simple file validation. e.g. > Inject code after GIF file signature. However, Ruby/Perl apps were not > reported as vulnerable > to script inclusion because usual image check, e.g. check image size, can > prevent > attack image to be stored. Any other files are failed as syntax errors. > > In contrast, PHP allows to embed script anywhere in a file. Image size check > does not > help at all. Converting size does not help also. (e.g. Attacker may embed > script in > color table. Changing size/recreating image cannot prevent attacks) If data > is written > into files, it can be used to execute. *Session data* file can be used to > attack, too. > These are the reason why file inclusion attacks against PHP applications > are so > popular/common. > > Any PHP applications do file upload (image/etc) or data file writes > (wiki/session data) have > much higher script inclusion risk compare to others. > > Other languages have fopen/readfile also. In this case, the result is the > same. > PHP is as safe as other languages in this area. > > PHP has became as secure as other languages _except_ script inclusion which > allows attackers take over servers. This is what I would like to change. > > We have been removed embedded script from regex, i.e > preg_relace/mb_ereg_replace, > because it is dangerous. Why don't we remove embedded script from > include/require. > include/require is used to execute attack script more often than regex. PHP7 > seems > perfect opportunity to me. > > Feasible options are > - Introduce script only inclusion statement. script()/script_once() > - Change require()/require_once() behavior not to embed script. > > Let's have no more script/file inclusion attacks! > > > Regards, > > P.S. Changing the result of bugs like this is defined as a security measure > by ISO 27000. I do not put high value in this ISO ;-) However, back to this exact feature. I am not convinced it is the right way, there are many cases required more than just checking valid code (<?php ...), like bash bang lines, phar or other script archives-like solutions. And even with this solution, a compromised server (via a web app or other) could still do whatever they want with php scripts if the web server is not configured correctly. This is and remains a OS level configuration problem. Cheers, -- Pierre @pierrejoye | http://www.libgd.org