Hi,
I changed one of my scripts to use FastCGI PHP. Therefore I renamed it to *.phpf. This is described in [1]. Unfortunally, this now shows the user the PHP source code. Fortunally, there were no sql passwords in this file... Is FastCGI available on the new server?
Sincerelly, Christian Thiele / APPER
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Christian Thiele:
I changed one of my scripts to use FastCGI PHP. Therefore I renamed it to *.phpf. This is described in [1].
this page is obsolete; PHP has been using FastCGI by default for the last few months. i removed the content of the page so it doesn't confuse people.
- river.
Hi,
Am 14.12.2008, 01:03 Uhr, schrieb River Tarnell river@loreley.flyingparchment.org.uk:
this page is obsolete; PHP has been using FastCGI by default for the last few months. i removed the content of the page so it doesn't confuse people.
maybe you could scan the server for *.phpf files, because these are security risks now. If there are other people like me, who had *.phpf scripts and didn't change them, the source of these scripts is readable by everyone (including database passwords and so on) now.
Sincerely, Christian Thiele / APPER
On Sun, Dec 14, 2008 at 1:38 AM, Christian Thiele apper@apper.de wrote:
Hi,
Am 14.12.2008, 01:03 Uhr, schrieb River Tarnell river@loreley.flyingparchment.org.uk:
this page is obsolete; PHP has been using FastCGI by default for the last few months. i removed the content of the page so it doesn't confuse people.
maybe you could scan the server for *.phpf files, because these are security risks now. If there are other people like me, who had *.phpf scripts and didn't change them, the source of these scripts is readable by everyone (including database passwords and so on) now.
It would of course be a good idea, but any PHP(f) file that is world readable and has passwords in it is inherently a security leak.
Bryan
On Sun, Dec 14, 2008 at 4:08 AM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
It would of course be a good idea, but any PHP(f) file that is world readable and has passwords in it is inherently a security leak.
So how do you store your passwords, such that the web server can read them to connect to the database but can't read them to serve the files containing the passwords?
On Sun, Dec 14, 2008 at 21:45, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
So how do you store your passwords, such that the web server can read them to connect to the database but can't read them to serve the files containing the passwords?
Every user has a ~/.my.cnf file outside the public_html directory. The file is readable by any scripts run on behalf of this user.
— Kalan
On Sun, Dec 14, 2008 at 9:54 AM, Kalan kalan.001@gmail.com wrote:
On Sun, Dec 14, 2008 at 21:45, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
So how do you store your passwords, such that the web server can read them to connect to the database but can't read them to serve the files containing the passwords?
Every user has a ~/.my.cnf file outside the public_html directory. The file is readable by any scripts run on behalf of this user.
Right, I forgot that on the toolserver scripts run as their owner and not the web server or a dedicated user.
On Sun, Dec 14, 2008 at 09:45:50AM -0500, Aryeh Gregor wrote:
On Sun, Dec 14, 2008 at 4:08 AM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
It would of course be a good idea, but any PHP(f) file that is world readable and has passwords in it is inherently a security leak.
So how do you store your passwords, such that the web server can read them to connect to the database but can't read them to serve the files containing the passwords?
The answer, which someone else already pointed out, is to put the password-containing files outside your personal web directory, such as in your ~/.my.cnf file, and set them so that only you can read them. Your cgi scripts run as your user id, not the webserver's user id.
I'm certain that this sort of UNIXy file security is a mystery to many users, so it ought to be documented somewhere. But, lacking that, here are a couple rules of thumb:
1) Never put a password directly in a cgi script. Make the script read passwords from some other dedicated configuration file.
2) Never assume that the source code of your cgi scripts is secret or secure.
3) Don't use your personal wiki password from your cgi scripts - make a separate account.
A side benefit of 1-2 is that it makes sharing your source code much easier. You don't run the risk of accidentally committing into svn a version of your code with a password in it. And you don't have to edit the code to hide the password when you send the code to someone else.
- Carl
To access my username and password for the SQL database, I just save this file as database.inc in my home forlder, and access them via $toolserver_username and $toolserver_password:
<?php $toolserver_username = get_current_user(); $toolserver_mycnf = file_get_contents("/home/".get_current_user ()."/.my.cnf"); if (!preg_match('/^\\s*password\\s*=\\s*"(.+)"\\s*$/im', $toolserver_mycnf, $toolserver_pwdlookup_matches)) die ("Can't find MySQL password"); $toolserver_password = $toolserver_pwdlookup_matches[1]; unset($toolserver_mycnf); unset($toolserver_pwdlookup_matches); ?>
On Dec 15, 2008, at 7:57 AM [Dec 15, 2008 ], Carl Beckhorn wrote:
On Sun, Dec 14, 2008 at 09:45:50AM -0500, Aryeh Gregor wrote:
On Sun, Dec 14, 2008 at 4:08 AM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
It would of course be a good idea, but any PHP(f) file that is world readable and has passwords in it is inherently a security leak.
So how do you store your passwords, such that the web server can read them to connect to the database but can't read them to serve the files containing the passwords?
The answer, which someone else already pointed out, is to put the password-containing files outside your personal web directory, such as in your ~/.my.cnf file, and set them so that only you can read them. Your cgi scripts run as your user id, not the webserver's user id.
I'm certain that this sort of UNIXy file security is a mystery to many users, so it ought to be documented somewhere. But, lacking that, here are a couple rules of thumb:
Never put a password directly in a cgi script. Make the script read passwords from some other dedicated configuration file.
Never assume that the source code of your cgi scripts is secret or secure.
Don't use your personal wiki password from your cgi scripts - make a separate account.
A side benefit of 1-2 is that it makes sharing your source code much easier. You don't run the risk of accidentally committing into svn a version of your code with a password in it. And you don't have to edit the code to hide the password when you send the code to someone else.
- Carl
Toolserver-l mailing list Toolserver-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/toolserver-l
toolserver-l@lists.wikimedia.org