7 replies to this topic

[Jon86]

The company I currently work for has McAfee audit all our sites. And since I'm the person who has to manage all the sites I have included my own site so I can test various web apps with Hacker Safe to see if their are any holes. So I will post here if McAfee flags anything that I am sure of is an osCommerce problem and not something to do with the server its running on!

Good news is Alpha5 (what I'm going to migrate our future sites to) actually passes its HackerSafe scan as of now with only a few minor problems. It dose fail the PCI (Payment Card Industry) scan, but that could be down to my servers security problems [haven't had the time to get them sorted] ANYWAY

The things McAfee are flagging now is simple and easy to fix. Directory listings! This is seen as a security problem as it reveals information. The solution is to simply put a blank index.html file in each directory that doesn't have one.

Basically image directories, thumbnail directories etc and any other place that will list the files in a directory if you browse to it directly like "www.somesite.com/some/directory/"

Edited by Jon86, 07 October 2009 - 09:13 PM.

[wilsonao]

Jon86, on 07 October 2009 - 09:13 PM, said:

The company I currently work for has McAfee audit all our sites. And since I'm the person who has to manage all the sites I have included my own site so I can test various web apps with Hacker Safe to see if their are any holes. So I will post here if McAfee flags anything that I am sure of is an osCommerce problem and not something to do with the server its running on!

Good news is Alpha5 (what I'm going to migrate our future sites to) actually passes its HackerSafe scan as of now with only a few minor problems. It dose fail the PCI (Payment Card Industry) scan, but that could be down to my servers security problems [haven't had the time to get them sorted] ANYWAY

The things McAfee are flagging now is simple and easy to fix. Directory listings! This is seen as a security problem as it reveals information. The solution is to simply put a blank index.html file in each directory that doesn't have one.

Basically image directories, thumbnail directories etc and any other place that will list the files in a directory if you browse to it directly like "www.somesite.com/some/directory/"

Great information.

Another good way to deal with directory listings is to disallow them in the .htaccess file. This is in general a pretty good practice. Just throw the following line in your .htaccess file:

Options -Indexes

[Jon86]

wilsonao, on 08 October 2009 - 03:12 AM, said:

Great information.

Another good way to deal with directory listings is to disallow them in the .htaccess file. This is in general a pretty good practice. Just throw the following line in your .htaccess file:

Options -Indexes

Yeah that's a good solution, you would be better just changing the server config to implement this though. I suggested including the blank index file as a way for osCommerse to do this 'out of the box' as the program will not (should not) be able to edit the .htaccess file and people might not know about this.

[ecartz]

The index.html method will only work on a server that is configured to look for index.html:  

	DirectoryIndex index.html

While that is the default, on a PHP server the default is usually overridden.  Showing directory listings is a bug in the server config and should be addressed there rather than adding four hundred blank index.html files to the distribution.  

Consider the case where you add a directory for something (e.g. if you want all product images for a particular manufacturer to be in a sub-directory of images).  Now there is a directory that is open to being viewed, because there is no way for osCommerce to add an index.html file to a directory that is added later, by an outside program.  

Properly securing an osCommerce site requires a properly configured server.  There's no getting around that.  An important example is securing the includes directory so that its files can't be hit as PHP files directly.  Or securing the images directory so that it won't allow PHP files to be run from there.  Or setting up the ownership and permissions of the images directory so that a generic server account can't write to it but the osCommerce admin can still add images to it.  

Adding blank index.html files is the wrong solution because it *mostly* works.  Because it mostly works, people will tend to act as if it entirely works.  It's better in my opinion to have a solution that doesn't work at all, because at least then it will be visibly not working and someone will be able to see that it needs fixed.  

Modifying the osCommerce .htaccess files is better, because even if that is not working, it completely does not work -- it even shows what needs to be done to get it to work.

[Jon86]

You've argued the point well, that is basically what I was getting at but couldn't find the words. The funny thing is McAfee suggest adding a blank index file as their solution!

[johnnybebad]

all this security is great but its getting hard to follow it all and have a true understanding of its importance.

I dont understand why there is an issue with the directories having to have index.php or index.html, however I have used this pratice in the past as a means of directing someone thats looking where they shouldnt be.

More recently I have installed the http error mod so that an url entered that doesnt exits gives a shop page with the error on it.

[Jon86]

If for example some attacker was probing your site. They will no be able to see all the files your site uses. Say index.php included and made a call to database.php and that had a vulnerability in it they could then exploit that if they knew it was their to exploit.

But even though it's not full proof and the proper solution is to write secure code, it makes it harder for an attacker to probe a site or get information about it. The contents of a directory is just a source of information. Not as critical as a password but its something that you don't need to share with the world.

[ctlee15]

ecartz, on 08 October 2009 - 10:38 PM, said:

The index.html method will only work on a server that is configured to look for index.html:  

	DirectoryIndex index.html

While that is the default, on a PHP server the default is usually overridden.  Showing directory listings is a bug in the server config and should be addressed there rather than adding four hundred blank index.html files to the distribution.  

Consider the case where you add a directory for something (e.g. if you want all product images for a particular manufacturer to be in a sub-directory of images).  Now there is a directory that is open to being viewed, because there is no way for osCommerce to add an index.html file to a directory that is added later, by an outside program.  

Properly securing an osCommerce site requires a properly configured server.  There's no getting around that.  An important example is securing the includes directory so that its files can't be hit as PHP files directly.  Or securing the images directory so that it won't allow PHP files to be run from there.  Or setting up the ownership and permissions of the images directory so that a generic server account can't write to it but the osCommerce admin can still add images to it.  

Adding blank index.html files is the wrong solution because it *mostly* works.  Because it mostly works, people will tend to act as if it entirely works.  It's better in my opinion to have a solution that doesn't work at all, because at least then it will be visibly not working and someone will be able to see that it needs fixed.  

Modifying the osCommerce .htaccess files is better, because even if that is not working, it completely does not work -- it even shows what needs to be done to get it to work.

I have a broad interest in security issues related to OsCommerce sites and decided to browse through this forum. You mentioned in your post a "properly configured" server is a requirement for securing an OSCommerce website. Could you elaborate a bit more on "how-to" properly secure a server for an OsCommerce site? Also, is this security method OSCommerce specific or once the server is secured for OSCommerce sites those same settings/configurations would apply to other PHP based applications??

Best,

Christopher