DSN Security

[ericbrunson]

An earlier post about security prompted me to ask this, I'm kind of in a quandry.

Running PHP as a module of Apache basically gives anyone with a little know-how access to any file that is readable by the web server process. Currently, I store config files with database username/passwords on the filesystem, but out of the document directories. But, if I had ftp access to a customer's account I could (and 90% of the readers of this forum could) write a simple PHP that would let me snoop the filesystem, and if I found those credentials I could acceess that customer's database freely.

It isn't currently a pressing matter, since none of our customers actually do their own PHP development. But that may not always be the case, and I have a client that wants me to start storing credit card information for people who shop on his site, and I'm *very* reluctant.

Is this a problem that has been resolved? I've considered encrypting the creds and prompting for a password at startup. That's kind of a hassle, but the best solution I've come up with the foil the average script kiddie. Other than that, I've considered SELinux and running PHP as a CGI (SELinux can only do a role-change during context switch).

Your thoughts are appreciated.

 

[MDLU]

good questions... if no one had ftp access, then they woudn't be able to get in, right? (unless they hacked in, of course) so this method would otherwise be secure?

 

[ericbrunson]

Let's just say file access. I forsee a day when some of our customers may want to do their own PHP coding and will need a way to update their code, as well as thier HTML pages.

FTP runs chroot, but I've heard chroot Apache is about as secure as XP, especially if you need mysql access.

 

[sleipnir214]

If FTP is chrooting the users, put the configuration files outside of any directory to which they have access. include() and require() will work across the entire filesystem.


Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[ericbrunson]

They would still be able to gain access to the config files by writing PHP code.

I several little <10 line scripts in Perl, Python, PHP and the like that simply allow me to run commands in that interpretter via system calls and display the output in a webpage. I use them for snooping around webservers I don't have shell access to. If one user's PHP script can read a config file, then how do you block a different user's PHP script from stumbling across it and reading it?

I guess most people here don't work in a shared web environment, like a hosting company.

 

[sleipnir214]

In such a case, I would use something like Zend Encoder to convert the necessary functionality into p-codes.

There's nothing that is going to stop someone who is sufficiently determined -- it's a matter of making what he gets in return worth less than the effort it causes him.


Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[KarveR]

I'd agree with Sleipnir here, zend encode would be my tool of choice in a shared environment, however for what you are suggesting in regards to the stored CC details, I would start by acquiring an entire webserver for myself, and then I'd feel somewhat happier.

______________________________________________________________________
There's no present like the time, they say. - Henry's Cat.

 

[Bastien]

I would strongly advise against storing cc data. If the server gets hacked,, either thru the app or via the OS/webserver holes, then you are screwed.

You are totally dependant on the hosts admins knowing what they are doing, actually doing it and doing it on time wrt exploits and hacks.

Store the transaction confirmation by all means, just not the cc data. Impress upon your client that this data is simply to sensitive to store, no matter how convienent its make things for the customer.



Bastien

Cat, the other other white meat

 

[ingresman]

You could change the two ports that ftp requires so at least they are hidden
or
block FTP and provide an upload page for the new code (in php)

 

[DRJ478]

IMO any comfortable level of security is not possible unless you run your own server. A shared PHP environment is not a place to store credit card information - the ramifications of possible exposure of such data are too serious.

If you don't have your own server then obscurity or encryption is your only choice. But, whoever has access to your encryption algorithms can decrypt, so we come back to your own server as a solution.

Otherwise, as almost everyone said here: stay away from such data.

As an alternative you could send your client the form data upon submission PGP encoded and he can deal with the storage of the CC data on his own IT platform.

 

[ericbrunson]

1) I am the server admin.
2) Security through obscurity is no security at all.

I think I'm just left getting a different server for clients who wish to do their own PHP programming. Especially, since I can get a decent rackmount for the price of Zend Encoder (which I don't have perfect faith in, anyway). I guess I can live with that.

I think I'll look into running PHP as a CGI which will allow me to use SELinux ACLs to protect the config files, but that's a ways down the line.

Thanks for all your input.

 

[MDLU]

i echo DRJ478's point. In addition, if someone's credit card or personal information is accessed and misused, you could risk getting sued big time for "allowing an unnecessary risk to exist" in such an environment.

-Jay

http://www.jaymunda.com