On Tue, Apr 10, 2012 at 4:51 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi all, > > I've written most of thing that I would like to mention for this RFC. > I tried to be precise and understandable for anyone. If you have > questions, you are welcomed both on this list and in private. > > Regards, > > P.S. Directly fixing bad English on wiki is certainly appreciated. > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I'm still unclear how LFI is a real concern. I have yet to see a sane example of code that is vulnerable. No one should ever write: include $_REQUEST['var']; include $_SESSION['var']; include $varFromDb; Do you have an example of real-life modern code that is vulnerable? The closest I've seen is some form of front controller: $pathParts = implode('/', $_SERVER['PATH_INFO']); $controllerClass = 'Controller' . $pathParts[0]; $controller = new $controllerClass; which then in the autoloader, uses the class name to include the file. Depending on the autoloader implementation, this is either invulnerable to LFI, or very, very unlikely to be exploitable. Now, as a webserver admin, maybe you have someone writing code that you don't trust, and can't control. I don't see how an optional non-embedded mode solves that problem, since it is a voluntary measure? Someone mentioned open_basedir as a mitigation, and I feel it is superior, since an admin can impose it without having to rely on voluntary compliance. If you want something stronger, then why not create something like:(note: this is not a real proposal) safeinclude "/some/base/dir", $file; which is equivalent to $origBasedir = ini_set('open_basedir', '/some/base/dir'); include "/some/base/dir/$file"; ini_set('open_basedir', $origBasedir); which allows the developer to specify where he expects the file to be, so that attackers can't manipulate the filename to access any location they want. summary: 1. Is there an example of modern, sane code that is vulnerable to LFI? (you mentioned some CVE's related to it, can you point them out?) 2. Isn't embedded vs. non-embedded mode a voluntary measure, thus not protecting those inexperienced enough to write code that is vulnerable to LFI? 3. Aren't there better options for protection against LFI?
