I agree that there should be a better way to store db connection data and
such in PHP. Since php scripts have to be readable by a webserver, that
usually makes them readable to the users on the box. Not necessarily, but
it requires custom setup to have it otherwise, and unless you have a true
access control file system, forget about making your scripts writable to one
group, read-only to the webserver and non-readable to every other user with
access to the box. Apache seems to be quite picky about file permissions as
that's bitten us a few times in the last week or so.
What I propose is the following. It makes life easier for the 95% of the
cases where there is one database being used most of the time.
Each database module (pgsql, mysql, oracle, etc) provides an additional
function, register_connection(), which takes the same arguments as the
(pg|mysql|etc)_connect() function for that database and stores the connect
data in some unreadable format on the filesystem perhaps within the php.ini
file itself. This function need only be called once, perhaps as a command
line program similar to htpasswd.
Each call then to _connect() with no arguments will pull the database
connection information written with register_connection() to make a
connection. Calls to _connect() with arguments will perform the way it does
now. That way if the user gets access to your site, he still will be unable
to do anything with your database without knowing something about its
layout. I.e. he can't do an _exec("DELETE FROM customer_data") unless he
knows that there is a customer_data table in that database.
On Linux mcrypt would be used. On windows, some other two way crypt module
would be used (J Smith mentioned Crypto++).
A feature such as this would place PHP a head and shoulder above any other
web scripting language that I know of. (I guess with C CGI modules that are
compiled you can't read the db connection info, but who wants to write CGI
or apache modules in C?)
Comments?
I just thought of another use for this "New Module" too. It would have to
be extended, but:
I would like to store a number of "configuration" or "site specific"
information in some non-user-readable way. This includes path information,
SQL queries. MD5 keys. Not sure exactly how this would shape up without
some kind of admin tool that ran on the server, but having this kind of
"embedded" databasing system would be pretty cool.
Anyway, if you've been able to follow my meandering, congratulations. I
just wanted to put in my $.02. I definitely don't have time to develop this
kind of thing right now, but think it would be very useful.
Joseph
> -----Original Message-----
> From: Keyser Soze [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 05, 2002 10:55 AM
> Cc: PHP-DEV
> Subject: Re: [PHP-DEV] New Module
>
>
> Not if the webserver is in another machine, he could have gained access to
> my system thru a security flaw in my webserver, one that doesn't
> have in my
> database server.
>
> And he just could create the script in a tempfolder and execute
> it if php is
> a cgi module, unless he has apache html write rights.
> I thought of this extension to make it harder for a hacker to access data,
> and easier for admins to detect the access from that data.
> But I thought a workaround for this case....I can modify the sources so
> cfg_get may store the last script who accessed that file, or maybe cfg_set
> could just grant access to one script....this could make impossible for
> anyone to create another script just to get it.
> I'm new in extension development, so I don't know if it's possible to know
> inside my function what script is calling it.
>
> hmmm, i hadn't noticed the PHP License....that sounds ok for me.
>
> regards,
> Keyser Soze
>
> ----- Original Message -----
> From: "Peter Petermann" <[EMAIL PROTECTED]>
> To: "Keyser Soze" <[EMAIL PROTECTED]>; "Robin Ericsson"
> <[EMAIL PROTECTED]>
> Cc: "PHP-DEV" <[EMAIL PROTECTED]>
> Sent: Tuesday, March 05, 2002 12:12 PM
> Subject: Re: [PHP-DEV] New Module
>
>
> > it's much easier to detect a modification of a script instead of just a
> "cat
> > dbconf.php".
> no need to modify a script.
> if a hacker has access to your webserver,
> in most cases he will be able to access your db server too.
> if not, in case of your extension
> it shouldnt be hard for him
> creating a small script for looking up the data
> in your tempfolder,
> gaining the data,
> and deleting it
>
> this is from point of detection the same class as doing a cat dbconf.php
> the Point is: your extension is not changing security.
>
> btw: why you want to put it under GPL?
> most extensions have PHP License,
> that could conflict.
>
> regards,
> Peter Petermann
> --
> Homepage: www.cyberfly.net
> PHP Usergroups: www.phpug.de - [EMAIL PROTECTED]
> PHP Infos: www.php-center.de - [EMAIL PROTECTED]
> VL-SRM Homepage: www.vl-srm.net - [EMAIL PROTECTED]
>
>
>
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
