Re: security and php

> I am a system administrator and currently we are playing to migrate all > our CGI (written in C) to php! But playing a little with php i got > worried about how services that need to keep username/password are > handled by php, for instance: For starters, you *could* have PHP running as a CGI wrapped by suExec (http://apache.org) Performance, however, would be not-so-hot, particularly after custom C code as your previous experience. Rumor had it at one point that Apache 2.0 would allow Modules to execute in a similar fashion to suExec -- Whether this feature has survived development/debug/QA phases is unknown to me. But it *might* be worth checking out. WARNING: You'd be way past the envelope of tested source code at that point. Not just with Apache as Beta software, but with PHP/Apache/MySQL interaction. OpenSource QA mostly consists of quantity of users pounding on stuff, versus a planned organized QA team. You *could* write a tiny C-module using PEAR, or even alter PHP's source code, to have the passord encoded as part of your PHP Module binary. Your username/password would then be buried somewhere in the binary of that module, so only a C disassembler would get it out. I *think* libphp4.so just needs to be executable for Apache, right?... Many admins set up different username/passwords for MySQL, depending on what "classes" of users need select/update/insert/delete access to which tables -- And the one username/password combo that is for general everyday access through your public site is stored in a file that the PHP user (default 'nobody') can read, but is in a directory tree that is not in the web tree and that other users cannot 'cd' to. PHP can http://php.net/include such a file, even though it is not visible in the web-tree via a browser, if the include_path is set properly in php.ini. Still, other users on the same server can read that file using PHP or Perl or anything else than can run as user 'nobody', so it's not great protection. Another option would be to buy the Zend Encoder, and encode the file that contains username/password info. Rather expensive for what you need right now, but it would save you writing/testing the C code to bury the username/password in a large enough block of binary, and you can move on to your "real" application. Of course, if at some point you want to install PHP code on somebody else's server, or just keep a lot of files on your own server protected, the Zend Encoder price becomes more reasonable. Again, only somebody with a lot of time on their hands, a thorough knowledge of the Zend engine, and a disassembler is going to be able to reverse-engineer this. Still, if they want it bad enough, they *can* -- There's pretty much *no* *way* to have your web server capable of reading/executing a file, and yet not have some other user on that machine capable of doing the same to masquerade as that MySQL user, if they work at it enough. It will be as as good as your CGI programs were, but no better. Well, maybe a little better, since C crackers/disassembler-experts exist, but I don't think there are any ZendEncoder cracker specialists yet... > All our CGI programs execute sql queries to a mysql server, they > contains the user name and password in order to login into the database. > Since these programs need only to be executed its read flags are turned > off. I need such a funcionality with php, but how can this be done? It seems to me though, that the barrier difference between nobody-executable and nobody-readable is not *that* different: If I can write a Perl/PHP script to execute your connect.cgi, it ain't all that more difficult from being able to read the username/password in your connect.php. Yeah, I have to write a little shell script. Not that big a deal, really, in most real-world scenarios. > PHP scripts not owned by the user that runs the web server are required > to have the read flag for all tuned on, ok? this makes its contents > readable by all my system users, right ? So how to put user > name/password information into such script in order to get it accessing > mysql, but without allowing any other user to get into its contents and > reading login/password information ? It doesn't have to be *world* readable -- You can chown -R your site to be the user that PHP runs as, and chomd -R 400 it. See <?php phpinfo();?> to find out what that user is, and edit httpd.conf to change it with "User" directive. So now, only people who can su to 'nobody' or who have access to write PHP/Perl/C code on your server are able to snarf those passwords. Let's face it -- If they can write PHP/Perl/C code and execute it on your server, your MySQL passwords for data that web-surfers can read is probably not your biggest worry. Also, check out "safe mode" That makes it harder for one user on a shared server to read another user's files with username/password info in them. This is more for use in a VirtualHost ISP environment, which I get the feeling you're not, but I could be wrong. -- Visit the Zend Store at http://www.zend.com/store/ Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm Volunteer a little time: http://chatmusic.com/volunteer.htm