views:

92

answers:

4

Hi, I am trying to help a friend moving a web-site from one web-hotel to another. The old place is already closed, I have only a flat tar file of what was in it.

I apologise if this is a basic question. I am new to this...

The web site contained html docs and one could download a little java application (to be loaded on mobile phone) to send data to the web site.

The mobile java application sent a string to URL=/php/register.php This php script included another php script, "../inc/db_login.php" which connected to a SQL DB using "$link=mysql_connect().". register.php did the SQL insert for putting the new sent data in the DB.

My question is basicaly, where I should put this 2 PHP files on the new website and what permissions the directories and files should have.

The old web server obviously had a /php and /inc directories. None of these exists on the new webserver... Should I create them? What permission should they have? I guess the reason for having the password in a separate php file was security... The /php and /inc directory probably had different permissions...

The new server has directories: /httpdos, /httpsdos, /cgi-bin, /conf (and some others probably irrelevant)

1) does the files-extension (.php) means something to the server: as PHP scripts are "included" in HTML code (between , does the server need to look at the file suffix or is it irrelevant? (I understand that the server reacts on the , of course)

2)should the "public" file (register.php in my case) be placed in the httpdocs directory or does the server (apache I think) reacts on something and fetches it in another directory?

3)Should the PHP script have permission R-X, --X or R-- ? From on OS perspective I guess apache is just reading this files, meaning that they should be R--, but this would mean that if PHP service is "stopped" the client would get all the PHP code in his browser(?). I would prefer it being --X but as this is neither a binary nor has a #!, I guess it must be --R...?

4)If the public PHP script can be placed in another dir (e.g /php instead of /httpdocs) what should /php (and the script) have for permission?. I Guess the server has to know about this /php directory (or are there usual defaults?)

5)The PHP script included (../inc/db_login.php, containing SQL password) should not be under /httpdocs I guess. This means that my register.php is including a file which is not under the /httpdocs subtree... Does this work? Does the server need to know?

I understand you may need to know the server configuration... Just assume the default in your answer (and you can tell where it is changed if it is).

I am new to this (PHP/SQL/ apache/ Web site) so be descriptive on this please. I know perl, python, C and linux rather well, less description needed there :-)

Many thanks.

/Christophe.

+1  A: 

Directories must have execute permissions to be usable. Usually this is 0755. PHP scripts run via mod_php are not executed but rather read; 0644 will suffice for this. Directories that must be written to need to be owned by the user the web server is running as. There may be additional concerns regarding permissions, e.g. SELinux, but the above will get you through the basics.

Documents that must not be accessed by other users or external clients should be 0600, owned by the web server user, and located outside the DocumentRoot. Note that running mod_php in Safe Mode will prevent scripts from ever including anything outside the DocumentRoot; a lamentable flaw.

Ignacio Vazquez-Abrams
Thanks for your answer. I'll put register.php in httpdocs/php.Now I tried to create /inc and to include ../../inc/db_login.php, but the creation of /inc was refused... should db_login.php be placed in cgi-bin then?. And if apache is in safe mode, then db_login must be in the httpdocs tree... isn't it a safety risk?
christophe milard
Nothing other than CGI scripts should be in `cgi-bin`. Yes, having config files under DocumentRoot is a potential security risk; PHP could solve this by having a config option that specifies an additional directory that can be explicitly included from. But it doesn't.
Ignacio Vazquez-Abrams
But if both register.php and db_login.php are under the html doc root and their permissions are the same, what is the gain (security wise) to have them in 2 differents files. I though that the idea was to have "more security" around the passwords included in db_login...? Isn't it a risk that the code gets to the client if PHP fails? Once again, many many thanks for your time. /C
christophe milard
The one thing you can do in that situation is to rely on httpd's behavior regarding dotted files; httpd will not allow exteral access to files whose name starts with a single dot, e.g. `.db_login.php`. The problem with that is that the file is now invisible by default to `ls` and similar tools, and it is easy to forget that it exists.
Ignacio Vazquez-Abrams
A: 

I've coded a function to address the permissions issues in both of PHP / SuPHP and similar:

function realChmod($path, $chmod = null)
{
    if (file_exists($path) === true)
    {
        if (is_null($chmod) === true)
        {
            $chmod = (is_file($path) === true) ? 644 : 755;

            if (in_array(get_current_user(), array('apache', 'httpd', 'nobody', 'system', 'webdaemon', 'www', 'www-data')) === true)
            {
                $chmod += 22;
            }
        }

        return chmod($path, octdec(intval($chmod)));
    }

    return false;
}

Maybe it's useful for you.

Alix Axel
You should consider using octal literals instead of dealing with that octdec() cruft, and use `|=` instead of `+=`.
Ignacio Vazquez-Abrams
You're using a PHP script to fix permissions on a PHP script? If the server's permissions are out of whack and not allowing PHP scripts to run, then this script will also not run. Though if you manually fix this script's permission, then you can use it to do a batch restore of the others. Might be just faster to use `chmod -R` from the command line, though.
MidnightLightning
@MidnightLightning: It is still possible to run PHP scripts via CLI even if it isn't working properly in the web server, assuming you have shell access of course. Also, `chmod -R` can be dangerous, better to use a properly crafted `find` instead.
Ignacio Vazquez-Abrams
But if both register.php and db_login.php are under the html doc root and their permissions are the same, what is the gain (security wise) to have them in 2 differents files. I though that the idea was to have "more security" around the passwords included in db_login...? Isn't it a risk that the code gets to the client if PHP fails?Once again, many many thanks for your time./C.
christophe milard
Splitting them is not necessarily for security, but for modularity. If another script needs access to the same database that register.php does, since the database functionality is separate, that new file can just include db_login.php and go, rather than re-writing that code in all scripts that need it. Plus if your database password ever changed, you'd have to change it in all files that used that database connection if you merged it, while in the current setup you'd just change it in one spot.
MidnightLightning
A: 

1) Files that end with a .php extension are handed off to the PHP compiler by Apache. If the proper configuration is not set up to do so, PHP files get served up as text files by the server. The Apache configuration line "AddHandler php5-script php" in the httpd.conf file is the PHP5 method of setting this up.

2) register.php needs to be accessible at http://www.example.com/php/register.php, as the java app is looking for it, so in the Apache htdocs folder, there needs to be a "php" folder with the register.php file in it.

3) PHP files need read access by the user that's running the Apache service. Using PHP as an Apache module has no 'service' to speak of that's separate for PHP. Instead the Apache service, when it gets a request for a PHP file, makes a shell call to the PHP binary to parse the file and hand the Apache service the result, which it serves to the client. Only if you were using PHP from the command line (CLI setup) would the scripts need execute permission, and start with a #!/path/to/php-bin line.

4) The requested file (register.php) needs to be in htdocs in order to be served by Apache. If PHP is running with "Safe Mode" disabled, register.php could include a file that was outside the htdocs folder.

5) The path "../inc/db_login.php" is relative to the PHP script that was originally fetched (register.php), so, since register.php is in htdocs/php/register.php, that would put db_login.php at htdocs/inc/db_login.php.

MidnightLightning
Point 3: CLI and CGI setups both need execute permissions.
Ignacio Vazquez-Abrams
A: 

All the PHP files which are intended to be addressed directly via URLs can happily reside in the same directories as the static content (this is the usual practice).

It is good practice to have at least one directory outside those visible from the webserver to hold include files, but the PHP include path should still include '.'.

I'd recommend not putting lots of non-standard directories in your root filesystem - the default webroot varies by distribution, but I usually go with something like:

/var/www/htdocs - as the document root /usr/local/php - for include files

Obviously if you intend running your webserver chrrot, these should be mapped accordingly.

All files must be readable by the uid under which the webserver runs, however if you can restrict what is writeable by this uid as much as possible then you close off a potential attack vector.

I usually go with setting up my dirs as drwxrwSr-x owned by a member of a webdev group with the group ownership as the webdev team, (the httpd uid is not in the webdev group) and files are therefore -rw-rw-r-- So anyone in the webdex group can change files, and the httpd uid can only read files.

1) does the files-extension (.php) means something to the server:

Yes - go read the PHP installation guide.

C.

symcbean