oh, yea - i forgot: i simply "do()" a little file at the beginning of my cgi-stuff, and that one connects to the db (and dumps out headers, etc), so i can change any setting there at the push of a button (and i can tell apache to ignore that init-file for security's sake). that works just fine - but does anybody now whether there are any mayor performance issues doing that?
....or is there a way to tell apache to provide a $dbh to all files that end in, say, .mpl? that'd be the most elegant solution, i guess... M. > -----Original Message----- > From: Dave Feinberg [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 11, 2001 3:05 PM > To: [EMAIL PROTECTED] > Subject: RE: security and dbi > > > hmmm interesting. I agree with you and our previous > writer. And as i replied, i would like to make it a little > more difficult. What you suggest however makes good sense. > Permissions are important. If you put it all in one file, it > is 1) easier to change when the password changes, 2) easier > to deal with permissions (you only need permissions on one file), and > 3) only 1 file to encrypt should we go that route. Thanks > for the suggestions. > -Dave > > > -----Original Message----- > From: Mr. Sunblade [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 11, 2001 3:56 PM > To: Dave Feinberg > Cc: [EMAIL PROTECTED] > Subject: Re: security and dbi > > > Dave Feinberg wrote: > > > ok this is a different ball of wax altogether :-) > We do use > > ssh instead of ftp to prevent network sniffing of data, but > i am not > > even looking at this yet how to prevent someone from sniffing the > > connection and > > stealing stuff. We use oracle. But that is an interesting > link thanks. > > We > > will have to solve this problem eventually as well, but for > now we are > > presuming it is all on an internal net so it is pretty > secure in that > > regard. > > -Dave > > Dave, > > Well, you have to accept the fact that if they can access > your scripts, they can ultimately get the login/password > information. In other words, if they've got root access, > you're effed anyway. > > That being said, you can avoid sniffing by non-root users > using any of the following simple techniques: > > 1) Permissions. Make all executables 700 and non-executables > 600 for the userid in question (assumes *nix style perms). > 2) A resource control file. I often use the .netrc file as a > double for login/password info for DB stuff. There's even a > handy Perl interface (called Net::Netrc). This keeps > login/password info out of the calling script and provides > enough security to keep any "accidents" from happening. > > 3) A continuation of 2, really. Encrypt the resource control > file and decrypt it programatically. Once again, however, if > they can read your calling script, they'll ultimately be able > to decipher the control file, too. > > All it really boils to is "how tough do you want to make it"? Just > remember - if someone has root access on your client/server, > DB access violations are probably going to be the least of > worries, considering they could wipe out everything anyway. > > Regards, > > Mr. Sunblade > > >
