Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59744
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKOpQSz1=AFfWcO=F0Ot_2Jm8audczE2a1DnGV-vxhp=80ZcUQ@mail.gmail.com>
References: <CAGa2bXZ6G=Cphjrde3u1Mq3AAw-4yJk3s28vNe+Aybt2nGTumg@mail.gmail.com>
	<CAGa2bXZh4uMeUH_BSCFmfNgxS-SZC0svA9BPcSROjwmbfrtFyQ@mail.gmail.com>
	<CAGa2bXbhi4zdgd9Udo6KsoycDwg_Ke0Xe5h3_-fVDMvn_VfAjQ@mail.gmail.com>
	<A633CF2D7C7BED41B41F1E64F25507B806A5CDD6C2@MAILR001.mail.lan>
	<CAGa2bXZKfQ+HqOucwOnBH7gV84hpdxZb5qNY3t3ThF_zMKSGHw@mail.gmail.com>
	<4F850D06.10701@sugarcrm.com>
	<CAGa2bXZWrRh8RdMtKK_2_U_XmByC-O6hGRPrJyW5KwvE0CAK-w@mail.gmail.com>
	<4F8515AF.8060706@sugarcrm.com>
	<CAGa2bXZWudQeRm5h2eENGmgQDPfOqEmijB9-vPAvfKXLCfDiLw@mail.gmail.com>
	<4F851FE4.7000706@sugarcrm.com>
	<CAGa2bXbXdNcfHX_dM2EVVz_2JtS4cc+8pxneSLAd382TuQUg-w@mail.gmail.com>
	<4F8539E0.1090701@sugarcrm.com>
	<4F859063.1010401@lerdorf.com>
	<A633CF2D7C7BED41B41F1E64F25507B806A5CDD71A@MAILR001.mail.lan>
	<CAKOpQSz1=AFfWcO=F0Ot_2Jm8audczE2a1DnGV-vxhp=80ZcUQ@mail.gmail.com>
Date: Wed, 11 Apr 2012 11:08:23 -0700
Message-ID: <CALKFbxs5irYW1Sdus4b=XBvbKqfsMkJbEd14RmXC7tFv7rg-fw@mail.gmail.com>
To: Kris Craig <kris.craig@gmail.com>
Cc: John Crenshaw <johncrenshaw@priacta.com>, Rasmus Lerdorf <rasmus@lerdorf.com>, 
	Stas Malyshev <smalyshev@sugarcrm.com>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: chrisstocktonaz@gmail.com (Chris Stockton)

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/RF=
I
> to begin with. =A0Personally, I would *never* check-off on code that in a=
ny
> way used $_GET or $_POST directly in an include/require statement! =A0It'=
s
> just plain lazy. =A0There's just no excuse for doing that. =A0Use some so=
rt of
> dispatch or translation table. =A0Sure, it might seem less "magical," but
> it'll also protect you from some asshole hitting you with something like,
> "?file=3Dhttp://hacksite.com/injectedcode.php?". =A0The individual code
> developer has to take *some* responsibility for their code. =A0If 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