NYCPHP Meetup

Tue Jul 30 11:06:27 EDT 2002

The security advantages I'm refering too have to do with centralizing the
security & modality checks.  By the checks being in 1 place, there's no
danger in adding a page to the system and forgetting to put the necessary
includes.  It seems to be a simpiler and less error prone design.  You may
disagree, but can you see where this design would be a bad thing?

I hadn't thought of the dummy frame for implementation hiding, I'll have to
give that some thought.  Although the implementation hiding in the single
entry point is more complete if you utilize simple encryption on the
variable that controls the "next page".  For instance, the design I'm
working with creates a sequence# + the next page encrypted with a system
key.  This means that all intersite links are giberish to someone looking at
page source.  It also means I can ensure the back button on the browser was
not hit, or the browsers history not used since these requests will have an
out of order sequence#.  It also makes it nearly impossible for a hacker to
submit a form that will be accepted from the server since the sequence# is
different every time that page is hit since it is based on 1) the initial
sequence# assigned to the session ( it's not 1 or 0, but a random range )
and 2) on the order the user chooses the pages.  A hacker may break past the
login security ( or be a valid user ) and navigate to the page they want to
hack & then attempt to circumvent the system since the source contains valid
encrypted links, but this makes hacking all the more trouble.  Add on top of
that usage log analysis showing the same user going though the same sequence
followed by errors raises flags you may have an attempted hack.  All the
while this implementation is hidden making the hack alot harder.  Not to say
a similar system could not be designed along side the normal links hidden
via the dummy frame, it just seems like it would be more work.

Jim

----- Original Message -----
From: "Oktay Altunergil" <nyphp at altunergil.com>
To: "NYPHP Talk" <talk at nyphp.org>
Sent: Tuesday, July 30, 2002 10:40 AM
Subject: Re: [nycphp-talk] single entry point

> I will have to disaggree with your conclusion that this kind of a design
will have major advantages regarding security.
>
> You could just seperate you security page (that checks whether the user is
signed in and has the required permissions) and include it in every page
(maybe along with stuff that you include anyway. .like the <HTML><HEAD>
stuff).
>
> I've found that what you're describing is good for template based sites.
For instance on freelinuxcd.org I use a very simple implementation of this.
All pages have the same table structure which keeps the look uniform, but
depending on the 'page' variable passed, the appropriate CONTENT is
displayed in the table cells. If you would like to take a look at the code
it's in http://freelinuxcd.org/download/latest/. There's no authentication
there simply because we have no use for it.
>
> Lastly, you can accomplish most of what you're describing by using a dummy
frame that keeps the url unchanged no matter which page you go to.
>
> cheers..
>
> Oktay
>
> On Tue, 30 Jul 2002 10:25:50 -0400
> Jim Hendricks <jim at bizcomputinginc.com> wrote:
>
> > As a fairly new PHP developer, I'm wrestling with not only learning the
> > lingo, but also attempting to discover best practice.  When I was first
> > faced with ASP when ASP was first introduced I made the design snafu of
> > developing my first small page as a single page.  Login, login
validation,
> > form entry, form validation and submission, and submission response all
> > rolled up into 1 .asp file.  While it was great for this 1 small app (
more
> > of an applet ), when the client wanted to add more stuff it required
> > re-arranging the app splitting it up, figuring out the then flawed
> > response.redirect etc.  It then required adding to the top of each page
the
> > security checks to ensure the user was logged in etc. ( of course added
as
> > an include ).
> >
> > Well to make a short story long, I encountered an ASP app written by
another
> > programmer which I was inheriting which used a single entry point(
> > everything went through default.asp ( ASP's equivalent of index.php ) ).
He
> > used an encrypted querystring parameter to key the ASP file as to which
page
> > was really required & then using a case statement included the necessary
> > files.  He must not have been aware of ASP's static include, all
includes
> > are included regardless of control logic around the include.  I did
think
> > the solution to be rather elegant, hiding the implementation from the
user
> > by only exposing 1 page.  Later as I developed it I even moved the
encrypted
> > parameter to a hidden form field to even hide that part of the
> > implementation.
> >
> > I've seen a few PHP apps floating around that use a similar design.  In
PHP
> > the obvious advantage over the ASP version is the dynamic include (
include
> > based on the surounding logic ).  I'm interested to get the opinion of
more
> > experienced PHP developers on this single entry point design.  I realize
> > this design will not allow search engines to index more than the entry
> > point, but I'm developing in an extranet environment where search
engines
> > are not desired anyway.
> >
> > I think one of the things that draws me to this solution is the ease of
> > security checks and forcing a specific modality ( ie. stopping the
browsers
> > back button & ensuring a specific work flow where required ).
> >
> > Please let me know your opinion on this.
> >
> > Jim
> >
> > _____________________________________________________________
> > Jim Hendricks, President, Biz Computing, Inc
> > Phone:  (201) 599-9380     Email: jim at bizcomputinginc.com
> > Web: www.bizcomputinginc.com
> > Snail:  Jim Hendricks,  Biz Computing, Inc.,  255 McKinley Ave, New
Milford,
> > NJ 07646
> >  ______________________________________________________________
> >
> >
> >
> >
>
>
>
>

NYCPHP Meetup

NYPHP.org

[nycphp-talk] single entry point