Security design questions

[Wescotte]

I'm currently working on desiging several web based applications that
would be grouped into a larger web based menu system. However I'm not
sure exactly how to go about making it as secure as possible.

I'm guessing most systems are setup in the following fashion. Create a
single user account (I'll reference this account as ROOT) that has
access to all the tables my applications will use.

Create a table for storage of username/passwords/userid # etc etc
Create a table with permissions details for each user userid # so when
the menu page is displayed it knows what programs to show to the user.

At the login page have the user enter their login and password. ROOT
accesses the user account table and verifies the entered information is
valid.

So the user is now logged in and page simply displays all applications
based on the permissions table for their userid #

I guess my questions are is this safe? If somebody is able to access my
login.php page (really any other pre parsed .php file) that uses the
ROOT account to access any other table they would essentially have
access to all applications.

As long as I don't allow access to my web data files via any other
method but HTTP can I ensure that my web server wouldn't allow users to
access pre parsed PHP files?

Any input/suggestions?
Thanks
Eric

[Gordon Burditt]

>I'm currently working on desiging several web based applications that

would be grouped into a larger web based menu system. However I'm not
sure exactly how to go about making it as secure as possible.
"as secure as possible" typically means "disconnect ed from the net,
powered off, and with the hard drive smashed into a thousand pieces,
buried 5 miles underground or launched into the sun".

What security policy are you trying to enforce?
I'm guessing most systems are setup in the following fashion. Create a
single user account (I'll reference this account as ROOT) that has
access to all the tables my applications will use.
That, as I understand it, is a *MySQL user* account. It has nothing
to do with a UNIX or Windows login account of the same or similar
name, except by coincidence.
Create a table for storage of username/passwords/userid # etc etc
These are *WEB user* accounts.
Create a table with permissions details for each user userid # so when
the menu page is displayed it knows what programs to show to the user.
If you are basing security on "if he can't see it, he can't use
it", that's not secure. Once he sees the link for it, he can then
use it. You need to check whether he's allowed to use it before
letting him use it, right when he clicks on the link.
At the login page have the user enter their login and password. *WEB user*ROOT *MySQL user*accesses the user account table and verifies the entered information is
valid. So the user is now logged in and page simply displays all applications
based on the permissions table for their userid #
When the web user attempts to use an application, a check should
be made whether he's authorized to use it. Depending on your login
setup, you may not have to re-verify the password (sessions can
handle keeping track of who the web user logged in as) but you need
to check "is user mike allowed to use the global_thermonu clear_war
application?" If not, display an error message and/or redirect
the user to the login page.
I guess my questions are is this safe? If somebody is able to access my
login.php page
(really any other pre parsed .php file)
What does pre-parsed have to do with it?
that uses the
ROOT account to access any other table they would essentially have
access to all applications. As long as I don't allow access to my web data files via any other
method but HTTP can I ensure that my web server wouldn't allow users to
access pre parsed PHP files?

Gordon L. Burditt

[Wescotte]

>That, as I understand it, is a *MySQL user* account. It has nothing

to do with a UNIX or Windows login account of the same or similar
name, except by coincidence.
I just used the term ROOT because that's the first thing that came to
mind.. I'm not using mySQL for the record, the database itself will be
most likely running off an AS400 DB2 system.
When the web user attempts to use an application, a check should
be made whether he's authorized to use it. Depending on your login
setup, you may not have to re-verify the password (sessions can
handle keeping track of who the web user logged in as) but you need
to check "is user mike allowed to use the global_thermonu clear_war
application? " If not, display an error message and/or redirect
the user to the login page.
Yes, every application will start with verifying if the user has access
to this particular application and if not will display an error message
and a link to the login page.
What does pre-parsed have to do with it?

I consider the code of my .php file pre-parsed... I probably didn't
explain it the best in the previous message..

Say I php file called RunSQLStatement .php and I included this file with
every other application that required access to the database. In this
file would be two functions. One to check if the user has permission
for a specified application and another to actually connect to the DB
perform a SQL statement and return any results.

Now I could simply have a constant in the
$connect = odbc_connect ("AS400", "ROOT","MY_ROOT _PSWD");

Now my issue is if anyone somehow accesses RunSQLStatement .php before
it's sent to PHP to be parased/processed and redirected to the user
they will have access to the entire database (provided they can connect
of course.. I'd also limit access to that account to the IP of the web
server)

I guess what I'm asking is this method generally acceptable? What are
other designs for web users? That sort of thing.

[Gordon Burditt]

>>That, as I understand it, is a *MySQL user* account. It has nothing

to do with a UNIX or Windows login account of the same or similar
name, except by coincidence.
I just used the term ROOT because that's the first thing that came to
mind.. I'm not using mySQL for the record, the database itself will be
most likely running off an AS400 DB2 system.

Ok, but it's still relevant to distinguish between different types
of "users": database (enforced by the database itself), application
or web users (enforced by the PHP application, possibly using data
in the database), and sometimes the privileges of system users (e.g.
the UNIX user id that Apache or PHP runs as).

When the web user attempts to use an application, a check should
be made whether he's authorized to use it. Depending on your login
setup, you may not have to re-verify the password (sessions can
handle keeping track of who the web user logged in as) but you need
to check "is user mike allowed to use the global_thermonu clear_war
application ?" If not, display an error message and/or redirect
the user to the login page.

Yes, every application will start with verifying if the user has access
to this particular application and if not will display an error message
and a link to the login page.

What does pre-parsed have to do with it?

pre-parsed: parsed before ... before WHAT?
I consider the code of my .php file pre-parsed... I probably didn't
explain it the best in the previous message..
I consider that terminology misleading, and I thought you might
mean "pre-compiled": turned into some binary mess that could be
executed faster because it's already been parsed. In any case, it
doesn't really have much to do with the security issues.
Say I php file called RunSQLStatement .php and I included this file with
every other application that required access to the database. In this
file would be two functions. One to check if the user has permission
for a specified application and another to actually connect to the DB
perform a SQL statement and return any results.
I think I'd call this "an include file of functions". It's a perfectly
reasonable way of handling common code.
Now I could simply have a constant in the
$connect = odbc_connect ("AS400", "ROOT","MY_ROOT _PSWD");

Now my issue is if anyone somehow accesses RunSQLStatement .php before
it's sent to PHP to be parased/processed and redirected to the user
they will have access to the entire database (provided they can connect
of course.. I'd also limit access to that account to the IP of the web
server)
I prefer to put database access info in an include file which is
*OUTSIDE* the document tree. It is possible for PHP to break, for
example, for a few seconds while you are upgrading it. (I really
should shut off Apache for this. Sometimes I forget). In that
situation, the .php file gets shown as text. Using my method, if
PHP is broken, the access info is outside the document tree, so the
web server won't serve it, and if it is NOT broken, PHP will interpret
it, and you'll see the output of it. Either way, the access info
is not sent to the user. The code using the access info uses the
variables, which are by convention always the same unless the page
happens to need *TWO* database connections (not unheard of when the
purpose is to migrate or check migration of data from one to another).

If you limit where access can come from, especially if it's localhost
(web server and database on the same box), even revealing the DB
password won't matter much except to someone with an account on the
same web server as you have (not at all uncommon with hosted servers).

<?php
$mysql_host = 'localhost';
$mysql_user = 'me';
$mysql_password = 'drowssap';
$mysql_db = 'database';
?>
Another advantage of this is that just by changing the include file,
or which include file I use, I can switch between the test and the
production database, or move the location of the database, assuming
I avoid cross-database references and use these variables consistently.
I use MySQL as an example, but other databases typically require
the same sort of information: what host is the database on (and
possibly which port), what authority do you have to use the database
(username & password, often) and which database are you using. The
details may vary a bit between different setups, but it's mostly
the same idea.

Note that this technique does NOT defend you against either (a) the
admin of your hosted web server, or (b) other customers (possibly
your competitors or thieves) on the same hosted box, unless the web
server uses different system user ids for each user (see mod_suphp
for Apache, or suEXEC). I believe most hosts don't use this.
I guess what I'm asking is this method generally acceptable? What are
other designs for web users? That sort of thing.

Keeping track of what user is logged in is best done with sessions
in most cases, since a lot of work has been done in this area that
is difficult to reproduce manually.

Incidentally, it is possible to use a session handler to store sessions
in a database rather than in little temporary files. This has the
advantage that sessions are available to multiple servers sharing
load via DNS round-robin rather than having them break horribly every
time the client goes to a different server.

Gordon L. Burditt

[Wescotte]

Thanks for all your input Gordon

[torpedo51]

Eric,
These items to help you with the concepts:

1. PHP is an HTML generator. PHP is executed on the server where it
generates HTML and sends that HTML to the client's browser. Web users
can't see your PHP source code (unless your web server is in the
condition that Gordon describes above). If your users can see your
source code, you have not configured your system correctly - stop now
and get help.

2. When using includes, consider your PHP pages as "one big page".
When you've included PHP from other files using include_once or
require_once, you're inserting that PHP code inline. Each and every
time you serve "one big page", you should check to see that the user is
authenticated (preferably near the top, so that you can reject the user
and stop generating HTML before you present the valuable info that
you're protecting). The same goes for db connectivity. Put those
includes near the top of every page request that you are serving.

3. Your PHP engine runs under its own account on the server, lets call
it "wwwrun". It acts as an agent for all your web users. The agent
serves pages to both non-authenticated users and to authenticated users
even *before* they can be authenticated. Once authenticated, the web
user has no influence on the PHP engine's agent... it continues to run
as "wwwrun". Read that again - once authenticated, your web-user still
has NO processes on your server. Authentication of a web-user only
provides one benefit - it allows you to decide what pages and data to
allow them to see. Keep in mind that there is a definite distinction
between machine accounts, and web-user accounts.

4. Your database should also have an account that acts as an agent to
broker all of your requests. The DB account should be less privileged
than the ROOT user account, and more privileged than an ordinary user
account. So, when you create your database, you will create ONE
database user account. Your PHP pages will contact your DB using this
agent. You might elect to use the "wwwuser" account that you already
have, or create a new account.

--Tim Talluto