On Fri, Feb 6, 2015 at 10:33 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi Pierre, > > On Fri, Feb 6, 2015 at 11:13 AM, Pierre Joye <pierre....@gmail.com> wrote: >> >> > I am :) Almost all of my clients are ISMS or similar certified. >> >> Marketing ;) >> >> >> 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. >> > >> > >> > With this proposal, <?php is allowed only at the top of a file. >> >> So phar won't work with require_script? If that's the case then it does >> look good to me. > > Good point! I'll add this to the RFC. > I'm not too familiar to phar format. > > Uncompressed phar has <?php at the top. I think .phar should be treated as > .php. > Compressed phar can be syntax error. I need to consider more including byte > compilers. > >> > For example, one of the easiest way to take over servers is embed >> > script into session data files. This is prevented effectively. >> > >> > Users who allows phar/etc file uploads, they may have encryption or >> > compression as mitigation. >> >> What does it have to do with upload? >> >> Uploads are and should not be in a folder where php can be executed. This >> is a basic configuration issue on almost all web servers. > > I agree that files are better/should be located other than web root. > Many apps only checks extension stores anything under web root. > > Even if uploaded files are stored under non web root dir, attackers can use > path > traversal or even full path with bad code. As long as PHP can access, > attacker > can access to files for inclusion attacks. Compression/encryption prevents > attack files executing via script()/require(). Does this answer to you?
Not really. One will have to use exec and call php and the desired file as a well configured server won't allow exec of php in the upload or tmp dir, via the web server. It does not mean they are outside a web doc root, only that no php (or other) will ever be executed from there. Also PHP is one part of the big picture, so I will simply summarize it as "as long as one can access" instead of "as long as PHP can access". That says all we need to know about emulating (badly anyway) OS security features in PHP. > I realized that I didn't think of byte compiler format. I have to research > it. > IIRC, Zend allows to have custom script loader. > Could anyone give some pointers to look around? or give some ideas? PHK and Phar f.e. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
