Design Model Question

[Mike Sutton]

I had first tried a less active PHP group, but let me try here.

I searched for this, but didn't find anything that appeared related.
Possibly I didn't know what to search for.

I am designing a web application using PHP, to which I am relatively
new. I have seen some sites use the model whereby a single index page
is created that handles authentication and receives option parameters
telling the index what to load in the body of the page. For example,
one could pass $page=AccountIndex.php to tell the index to include the
account index page using:
require_once $page;

And the link to get there would look like:
<a href="<?=$_SERVER['PHP_SELF']?>?page=AccountIndex.php">Account
Index</a>

Alternatively, the link could actually refer to a different page
(e.g., <a href="./AccountIndex.php">Account Index</a>) and that could
be loaded using its own authentication and receive its own parameters.

I hope this is sufficiently clear.

The questions are:
Can anyone provide opinions on advantages/disadvantages to each of
these models?
Can anyone provide the correct terminology to discuss these ideas so
that I can look for more, relevant resources.

Thank you,
Mike

[Gregor Favre]

Hi Mike

I am designing a web application using PHP, to which I am relatively
new. I have seen some sites use the model whereby a single index page
is created that handles authentication and receives option parameters
telling the index what to load in the body of the page. For example,
one could pass $page=AccountIndex.php to tell the index to include the
account index page using:
require_once $page;

And the link to get there would look like:
<a href="<?=$_SERVER['PHP_SELF']?>?page=AccountIndex.php">Account
Index</a>

What happens, if someone types into his browser:
http://www.example.com/index.php?pag.../../etc/passwd ? He'll get all
users on your system, and if the passwords are not shadowed, he gets these
too. This will work with every file on your system, so desist using this
method without any further checkings.

I prefer the method of serializing my pages with a number, the nuber being
the primary key of my pages in a database. Of course this works also without
any database, just do the work with a 'case statement' or so...

Greetings, Greg

[Chung Leong]

"Mike Sutton" <su*******@yahoo.com> wrote in message
news:7e**************************@posting.google.c om...

The questions are:
Can anyone provide opinions on advantages/disadvantages to each of
these models?
Can anyone provide the correct terminology to discuss these ideas so
that I can look for more, relevant resources.

I was just talking about this in another thread. DON'T USE THE SINGLE ENTRY
POINT ARCHITECTURE! It offers no advantages at all, while its disadvantages
are numerous. First and foremost, this architecture is one of the leading
causes of security breach in PHP site. By setting $page to an Internet
address (http://www.example.net/page=http://1...3.34/hack.txt), I can
run arbitrary code on your server. And I can bypass your authentication
scheme by simply typing in the address to the file that you're including
(http://www.example.net/AccountIndex.php).

People who use this kind of scheme, I dare say, don't have a strong
programming background. Those who have programmed in C/C++ or other
procedural languages know that you include a file to make additional
functionalities available, not to cause something to occur. Think about it,
when you use require() you're just stating the file is needed by the current
script.

The proper way to share code between script is to enclose it in functions,
keep these in an separate file, include it where it's needed, then call the
functions. Or for the sake of convinence, just include it in every script.

Here's an example setup: We have a file call global.php that's included into
every script. This file in turn, includes files with commonly used
functions.

global.php:
<?

require("../inc/auth.php");
require("../inc/interface.php");
require("../inc/db.php");

....

//error_reporting(E_ALL);
define(DEBUG, false);

?>

accountIndex.php:
<?

require("global.php");

RestrictAccess();

PrintHeader("Accounting");

PrintFooter();

?>

inc/auth.php
<?

function RestrictAccess($level = 5) {
if(empty($_SESSION["logged_$level"])) {
Redirect("login.php?level=$level");
}
}

?>

In this system, it's easy to have pages that require the user to log in and
others that do not. If you don't call RestrictAccess() then there's no
restriction. And it's easy to implement multi-level security. Just pass a
value to the function instead of employing the default if the page needs
extra security.

[Michael Austin]

Gregor Favre wrote:

Hi Mike

I am designing a web application using PHP, to which I am relatively
new. I have seen some sites use the model whereby a single index page
is created that handles authentication and receives option parameters
telling the index what to load in the body of the page. For example,
one could pass $page=AccountIndex.php to tell the index to include the
account index page using:
require_once $page;

And the link to get there would look like:
<a href="<?=$_SERVER['PHP_SELF']?>?page=AccountIndex.php">Account
Index</a>

What happens, if someone types into his browser:
http://www.example.com/index.php?pag.../../etc/passwd ? He'll get all
users on your system, and if the passwords are not shadowed, he gets these
too. This will work with every file on your system, so desist using this
method without any further checkings.

I prefer the method of serializing my pages with a number, the nuber being
the primary key of my pages in a database. Of course this works also without
any database, just do the work with a 'case statement' or so...

Greetings, Greg

I agree with you Greg.. unless of course you are using OpenVMS
(DEC/Alpha RISC CPU), then you can try, but you won't get very far... :)

Michael Austin.

[Mike Sutton]

> What happens, if someone types into his browser:

http://www.example.com/index.php?pag.../../etc/passwd ?

I hadn't addressed input validation as part of my question, but if a
user entered the string you proposed it would fail validation and they
would get a denied message.

Any other thoughts?

[Tony Marston]

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:S7********************@comcast.com...

"Mike Sutton" <su*******@yahoo.com> wrote in message
news:7e**************************@posting.google.c om...

The questions are:
Can anyone provide opinions on advantages/disadvantages to each of
these models?
Can anyone provide the correct terminology to discuss these ideas so
that I can look for more, relevant resources.
I was just talking about this in another thread. DON'T USE THE SINGLE

ENTRY POINT ARCHITECTURE! It offers no advantages at all, while its disadvantages are numerous. First and foremost, this architecture is one of the leading
causes of security breach in PHP site. By setting $page to an Internet
address (http://www.example.net/page=http://1...3.34/hack.txt), I can
run arbitrary code on your server. And I can bypass your authentication
scheme by simply typing in the address to the file that you're including
(http://www.example.net/AccountIndex.php).

People who use this kind of scheme, I dare say, don't have a strong
programming background. Those who have programmed in C/C++ or other
procedural languages know that you include a file to make additional
functionalities available, not to cause something to occur. Think about it, when you use require() you're just stating the file is needed by the current script.

The proper way to share code between script is to enclose it in functions,
keep these in an separate file, include it where it's needed, then call the functions. Or for the sake of convinence, just include it in every

script.

A single entry point architecture is sometimes known as a Front Controller
as every request goes through a single page. I much prefer having a separate
URL for each page as it gives me all the control I need without any of the
security problems. Take a look at
http://www.tonymarston.net/php-mysql...plication.html for a
description of a sample application which you can run online. There is also
a link to download all the code.

HTH.

--
Tony Marston

http://www.tonymarston.net

[CJ Llewellyn]

"Mike Sutton" <su*******@yahoo.com> wrote in message
news:7e**************************@posting.google.c om...

What happens, if someone types into his browser:
http://www.example.com/index.php?pag.../../etc/passwd ?

I hadn't addressed input validation as part of my question, but if a
user entered the string you proposed it would fail validation and they
would get a denied message.

Only if you are smart enough to validate the entry. I've seen plenty of
sites that haven't been protected ;)

Most php programs follow the same pattern

authentication
validation of input
processing of data
display of output

The single point of entry system allows you to contain the first and last
elements in a single script, and only include the elements for data process
where needed. This should in theory provide a lower overhead in memory and
CPU cycles as you are only loading the programming libraries your script is
using.

[Five Cats]

In message <cb**********@slavica.ukpost.com>, CJ Llewellyn
<sa****@tmslifeline.com> writes

"Mike Sutton" <su*******@yahoo.com> wrote in message
news:7e**************************@posting.google. com...

> What happens, if someone types into his browser:
> http://www.example.com/index.php?pag.../../etc/passwd ?
I hadn't addressed input validation as part of my question, but if a
user entered the string you proposed it would fail validation and they
would get a denied message.

Only if you are smart enough to validate the entry. I've seen plenty of
sites that haven't been protected ;)

Yes....

Most php programs follow the same pattern

authentication
validation of input
processing of data
display of output
So do lots of non-PHP programs in various ways.

The single point of entry system allows you to contain the first and last
elements in a single script, and only include the elements for data process
where needed. This should in theory provide a lower overhead in memory and
CPU cycles as you are only loading the programming libraries your script is
using.

--
Five Cats
Email to: cats_spam at uk2 dot net

[FLEB]

Regarding this well-known quote, often attributed to Five Cats's famous
"Sat, 26 Jun 2004 21:11:47 +0100" speech:

In message <cb**********@slavica.ukpost.com>, CJ Llewellyn
<sa****@tmslifeline.com> writes

"Mike Sutton" <su*******@yahoo.com> wrote in message
news:7e**************************@posting.google .com...

> What happens, if someone types into his browser:
> http://www.example.com/index.php?pag.../../etc/passwd ?

I hadn't addressed input validation as part of my question, but if a
user entered the string you proposed it would fail validation and they
would get a denied message.

Only if you are smart enough to validate the entry. I've seen plenty of
sites that haven't been protected ;)

Yes....

Most php programs follow the same pattern

authentication
validation of input
processing of data
display of output

So do lots of non-PHP programs in various ways.

The single point of entry system allows you to contain the first and last
elements in a single script, and only include the elements for data process
where needed. This should in theory provide a lower overhead in memory and
CPU cycles as you are only loading the programming libraries your script is
using.

You'd get the same benefits, with more security, using common
header/footer/wrapper includes, though, wouldn't you?
--
-- Rudy Fleminger
-- [e-mail]
(put "Hey!" in the Subject line for priority processing!)
-- http://www.pixelsaredead.com

[Mike Sutton]

"Chung Leong" <ch***********@hotmail.com> wrote in message news:<S7********************@comcast.com>...

[Y]ou include a file to make additional
functionalities available, not to cause
something to occur.

An excellent point, and one I hadn't considered despite the fact that
I would not do the same thing in other development environments.

Thank you.

[Chung Leong]

"CJ Llewellyn" <sa****@tmslifeline.com> wrote in message
news:cb**********@slavica.ukpost.com...

"Mike Sutton" <su*******@yahoo.com> wrote in message
news:7e**************************@posting.google.c om...

What happens, if someone types into his browser:
http://www.example.com/index.php?pag.../../etc/passwd ?

I hadn't addressed input validation as part of my question, but if a
user entered the string you proposed it would fail validation and they
would get a denied message.

Only if you are smart enough to validate the entry. I've seen plenty of
sites that haven't been protected ;)

Most php programs follow the same pattern

authentication
validation of input
processing of data
display of output

It's a mistake to split validation and processing into separate parts, since
the question of what is valid and what isn't is dependent what you the
process is. And there are error conditions that can't be detected until you
actually start processing the input.

[Chung Leong]

"Mike Sutton" <su*******@yahoo.com> wrote in message
news:7e**************************@posting.google.c om...

What happens, if someone types into his browser:
http://www.example.com/index.php?pag.../../etc/passwd ?

I hadn't addressed input validation as part of my question, but if a
user entered the string you proposed it would fail validation and they
would get a denied message.

The point is you shouldn't have to do that kind of validation in the first
place, since file-level access control is the responsibility of the web
server. It's stupid to create a run-around of the web server's security,
then build your own system.

[CJ Llewellyn]

"FLEB" <so*********@mmers.and.evil.ones.will.bow-down-to.us> wrote in
message news:1g****************************@40tude.net...

Regarding this well-known quote, often attributed to Five Cats's famous
"Sat, 26 Jun 2004 21:11:47 +0100" speech:

In message <cb**********@slavica.ukpost.com>, CJ Llewellyn
<sa****@tmslifeline.com> writes

"Mike Sutton" <su*******@yahoo.com> wrote in message
news:7e**************************@posting.google .com...
> What happens, if someone types into his browser:
> http://www.example.com/index.php?pag.../../etc/passwd ?

I hadn't addressed input validation as part of my question, but if a
user entered the string you proposed it would fail validation and they
would get a denied message.

Only if you are smart enough to validate the entry. I've seen plenty of
sites that haven't been protected ;)

Yes....

Most php programs follow the same pattern

authentication
validation of input
processing of data
display of output

So do lots of non-PHP programs in various ways.

The single point of entry system allows you to contain the first and lastelements in a single script, and only include the elements for data processwhere needed. This should in theory provide a lower overhead in memory andCPU cycles as you are only loading the programming libraries your script isusing.

You'd get the same benefits, with more security, using common
header/footer/wrapper includes, though, wouldn't you?

You end up writing the same

include('html/header.html');
include('html/footer.html');

statements in each file, unless you do what I do and have a common sub file
to process output.

[Terence]

Mike Sutton wrote:

I had first tried a less active PHP group, but let me try here.
The best place that I found for this sort of discussion is the advanced
PHP forum at sitepoint.com
The questions are:
Can anyone provide opinions on advantages/disadvantages to each of
these models?
Can anyone provide the correct terminology to discuss these ideas so
that I can look for more, relevant resources.

As Tony pointed out, the design pattern you refer it is specifically,
the "front controller" which is usually part of a more general pattern
called the "Model View Controller" (MVC) for which there are variants
such as Model2.

MVC has been pushed as "THE way to go" by some people and outright
rejected by others (particularly the front controller). Personally, I
use it only occasionally and only where I think it will speed up my
development. The front controller is good at solving the problem of
centralising code. There are many ways to do that tho. I tend to use a
front controller in very small applications that have limited
complexity. Sometimes I will use an FC in one module of a larger
application - this may sound ad-hoc but it isn't if the application uses
a higher level framework where sub-components may choose to be an FC.

As far as the security issues are concerned, there are easy ways to
address this with an FC. The FC method doesn't imply a security problem.
Ignoring the obvious [security implications of get requests] does. The
[get request] security issue doesn't require an FC to manifest itself.
Just use common sense.

Whatever you do, don't be too prescriptive about whatever design pattern
it is you decide is "the best way to build web apps". Things change,
including ideas. Learn to understand design patterns such as the front
controller and pick and choose the right times to take advange of it's
strengths.

Here is a good article written a while ago which discusses the
disadvantages with the FC pattern.
http://www.phppatterns.com/index.php...leview/81/1/1/
It's just a "discussion" and I don't agree with everything, but it's
food for thought.

cheers.