Permissions 777

[Rob22]

Got warnings from a security checking script, that most files in catalog/images have permission 777. Same is true for most PHP files in catalog/includes/languages/...

 

Is this the default behavior of OSCommerce, or probably some reminiscent from some older installation.

 

There is no reason to have execute permission set on these files, when PHP runs as an apache module.

 

I'd like to set permission to 644 and chown to current user on the PHP files and permission to 644 and chown to webserver on the image files. Do you think this will break anything within OSCommerce.

 

And is there a setting to prevent OSCommerce from uploading images with permission 777 in the future?

 

Thanks for any answers.

 

Rob

[usernamenone]

When you downloaded oscommerce it was all read and writeable.

 

Once you upload your catalog the permission level of you catalog is set by the server your site was uploaded to.

 

Some hosted sites do not have to adjust any permissions except the 2 configure.php files. Some hosted servers make read only for all uploaded files to their server.

 

Having to set the permissions on the oscommerce side will not and does not have to be done as it is server side that you are dealing with.

[Rob22]

Hi lola,

 

don't fully understand what you mean.

 

But recently found the following file in oscommerce:

 

catalog/admin/includes/classes/upload.php

 

which contains the following code:

  class upload {
var $file, $filename, $destination, $permissions, $extensions, $tmp_filename, $message_location;

function upload($file = '', $destination = '', $permissions = '777', $extensions = '') {
  $this->set_file($file);

 

So the 777 upload permission is hardcoded into oscommerce. If I change it to 644 the uploaded pictures have 644 permission.

 

Still don't understand, why oscommerce is doing this as it seems to be a security risk to upload files world writeable and world executable to the webspace of a sever, if there is no need for such permissions.

 

So I would call this a security bug. Strange, that no one has reported this so far!?!

 

Rob

[usernamenone]

I'm not too sure why you think this is a bug.

 

And while this permission may work on your server it will not work on all hosted servers.

[Rob22]

Well, it needs more to break into a server than just a few JPEGs with 777 permission. But it makes life much easier for a hacker once he has a foot in the door, when there are a lot of files with 777 permission lying around on the server, waiting for him to replace picture content with executable code.

 

IMHO it counteracts the idea of unix permissions, if a script - and I have no other explanation for OSCommerce' behavior - sets uploaded files to 777 permission in a mood, just because this is the permission with least probabilities, that people encounter a permission denied error. In case OSCommerce needs to upload files world writable / world executable - which I do not believe it has to - it should upload just these files 777 and everything else 644.

 

I changed the script to 644 now and monitor, whether OSCommerce shows any problems with this patch.

 

Rob

[usernamenone]

Here is the deal with the images folder and 777 or read and wright permissions.

 

Before initial installation, you should set your images folder to read/write, so that you can use the Admin interface to upload product/category images without having to use FTP for each one. Similar recommendations are made to other files for various reasons.

 

However, leaving the images (or any other) folder in read/write mode means that hackers might be able to put malicious files in this (or other) folder(s) and thus create access points from which to attempt nasty exploits.

 

Thus, once your site is built and your images have been created/loaded, you should drop the security down from read/write to read. ie: change from CHMOD 777 down to 644.

 

Inside each image folder should be a blank index.html file.

 

 

File/Folder permissions settings

On Linux/Unix hosts, generally, permission-setting recommendations for basic security are:

 

• folders/directories: 755
  
• files: 644
  

On Windows hosts, setting files read-only is usually sufficient. Should double-check that the Internet Guest Account has limited (read-only) access.

 

 

Folder Purposes

The folders for which installation suggests read-write access for setup are these. If your site supports .htaccess protection, then you should use it for these folders.

 

• /cache
  This is used to cache session and database information. The BEST security protection for this is to move it to a folder "above" the webroot (public_html or htdocs or www) area, so that it's not accessible via a browser. (Requires changes to DIR_FS_SQL_CACHE setting in configure.php files as well as Admin > Configuration > Sessions > Session Directory.)
  
• /images
  
• /includes/languages/english
  
• /pub
  This is used on Linux/Unix hosts to have downloadable products made available to customers via a secure delivery method which doesn't disclose the 'real' location of files/data on your server (so that people can't share a URL and have their friends steal downloads from your site)
  
• /admin/backups
  This is used by automated backup routines to store database backups. Optional.
  
• /admin/images/graphs
  This is used by the Admin > Tools > Banner Manager for updating/displaying bar graphs related to banner usage. If not writable, feature is ignored.
  

Things to Check Up on Regularly

1. Be sure you've done all the steps listed in this document
   
2. Keep good backups of your website files and database
   
3. Check your server's errorlog regularly for odd or suspicious activity
   • look for any links that went to a page that isn't in your site
     
   • look for links that have http after the index.php
     

[*]Check your website files regularly to be sure nothing's been added or altered

[*]Ask your webhost what they have done to be sure the server you're on is safe and secure so that outsiders cannot do any harm, and so that other websites on your server cannot be used to get to your site and cause any harm (in case they have security holes in them)

Added steps for security. Remove the print URL from your browser's headers

To stop the browser from printing a URL on the invoice or any other document on the web, follow these steps:

For the Microsoft Internet Explorer

o Click on File then Page Setup

o At page setup, remove this two character combination: "&u" from the header or footer text box.

 

So, you see it is not a bug at all and there is a reason for the 777 permissions. However we have not been told in any documentation that I have read to change those permissions back to read only for our web sites protection after uploading and adding product to our online shops.

 

 

Well, it needs more to break into a server than just a few JPEGs with 777 permission. But it makes life much easier for a hacker once he has a foot in the door, when there are a lot of files with 777 permission lying around on the server, waiting for him to replace picture content with executable code.

 

IMHO it counteracts the idea of unix permissions, if a script - and I have no other explanation for OSCommerce' behavior - sets uploaded files to 777 permission in a mood, just because this is the permission with least probabilities, that people encounter a permission denied error. In case OSCommerce needs to upload files world writable / world executable - which I do not believe it has to - it should upload just these files 777 and everything else 644.

 

I changed the script to 644 now and monitor, whether OSCommerce shows any problems with this patch.

 

Rob