473,325 Members | 2,860 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,325 software developers and data experts.

Security design questions

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

Jul 21 '05 #1
5 1477
>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 "disconnected 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_thermonuclear_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
Jul 21 '05 #2
>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_thermonuclear_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.

Jul 21 '05 #3
>>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_thermonuclear_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
Jul 21 '05 #4
Thanks for all your input Gordon

Jul 21 '05 #5
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

Jul 21 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Simon Hadler | last post by:
Hi was asking some questions about this in alt.php but some didn't get answered. Yes I have read an awful lot now about php security and different advisories and Idon't mind being called a...
3
by: craig | last post by:
I am working on my first .NET development project that involves custom role-based security per the project requirements. This lead to a general design issue this week that really caused us some...
0
by: Mathew Michuta | last post by:
I am going to use webservices extensively in my vb windows forms application. I will be exchanging lots of data over the internet in my distributed app. I purchased a certificate from verisign to...
116
by: Mike MacSween | last post by:
S**t for brains strikes again! Why did I do that? When I met the clients and at some point they vaguely asked whether eventually would it be possible to have some people who could read the data...
1
by: xmp333 | last post by:
Hi, I created an Access XP database, and then disabled all the menus that allowed users to modify report design, etc... (I'll call them administrative features). Users were only able to use...
7
by: lauren quantrell | last post by:
Are mde and ade files really secure? I don't want to know how to do it, but is it possible for someone to crack an mde or ade file and then open it as if it was not secured? lq
6
by: google | last post by:
I have a few general questions. I am working on a new database to be used within my company. I would like to give a couple of people, particularly HR, the ability to add and delete Access users,...
7
by: nugget | last post by:
Role-based security for an ASP/ASP.NET mixed environment Hello: My co-worker and I have been charged with designing role-based security for our intranet. The technologies we have to work with...
0
by: YellowFin Announcements | last post by:
Introduction Usability and relevance have been identified as the major factors preventing mass adoption of Business Intelligence applications. What we have today are traditional BI tools that...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.