Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58910
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F57D47E.1000804@gmail.com>
References: <CAJzDObekVt_F6JZP-B-YCs0khvfcSDW1PNeC6Bf5LUk=xPqVAQ@mail.gmail.com>
	<4F55DB1F.5040108@sugarcrm.com>
	<CAJzDObcwd6KMSNvJa8mui0QGiof+BEMoJ2WuGEq09uN+yc4n+g@mail.gmail.com>
	<4F567FD9.2050609@gmail.com>
	<CAJzDObcEUscO7q=h0DToEwvrxZMDnWFxjZnmWrsWxx+CKDkVxg@mail.gmail.com>
	<4F57D47E.1000804@gmail.com>
Date: Tue, 13 Mar 2012 02:39:32 -0400
Message-ID: <CAJzDObcT62byEbNREFEnPGcnSzc_r6PdWPK9B4kiaM3LMK-Nqg@mail.gmail.com>
To: =?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?= <keisial@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044797131cc79004bb1a1f32
Subject: Re: [PHP-DEV] Providing sandboxed versions of include and require
 language constructs
From: adamjonr@gmail.com (Adam Jon Richardson)

--f46d044797131cc79004bb1a1f32
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/3/7 =C1ngel Gonz=E1lez <keisial@gmail.com>

> On 07/03/12 00:04, Adam Jon Richardson wrote:
> > It would be the responsibility of the framework or CMS or application
> > to protect against this type of attack (which they do quite well.)
> > When you can force a plugin to work through your API, you can take
> > appropriate measures. When the plugin can avoid working through, say,
> > a file API that protects against misuse by using the internal file
> > functions, this is a much more difficult issue to mitigate.
> The key point is precisely, how do you ensure they can only call your API=
?
>

The idea would be to have a default whitelist of internal functions that
can be easily expanded per include as needed. That way, the script
including another script can determine how much power/trust they're willing
to hand off.

For example:

// EXAMPLE 1: included script would only be able to call functions found in
default whitelist
include_restricted('file/path1');

// EXAMPLE 2: included script would only be able to call functions found in
default whitelist and PDO
include_restricted('file/path2', $whitelist =3D array(SANDBOX_PDO));

The types of restrictions that involve restricting calls to internal
functions (e.g., file()) are, at least conceptually, is straight forward.
However, PDO has an object interface. For objects, I'm researching the idea
of limiting the creation of new objects within the included script. That is
to say that in example 1, the included script would raise an error if it
tried to create a PDO object directly.

However, in some situations, the framework or CMS may hand off a PDO object
to the included script or expose a factory API (maybe the intent is to
share a DB connection), and in this case, the sandbox would allow the PDO
object to be utilized within the script. The idea is for the framework/CMS
to be the gatekeeper for all of the applications resources, and if the
framework designers want to hand off an object for use, then that fits with
the general model I'm proposing.

Right now, it's very difficult to enforce any restrictions on included
scripts because they have access to all of the internal functions available
to the framework/CMS (using something like the disable_functions directive
limits the framework/CMS too much and works from a blacklist approach.)

I'm not saying this would be easy to implement, or that it would be
perfectly secure. I am saying that it's worth careful examination and that
there are many potential solutions that could make things better in terms
of application security.

Thanks for the feedback,

Adam

--f46d044797131cc79004bb1a1f32--