Hi Pierre, On Thu, Feb 5, 2015 at 8:49 PM, Pierre Joye <pierre....@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. -- Yasuo Ohgaki yohg...@ohgaki.net
