DevHeads.net

Revisited: 500 internal server error, new problem

OK I have a somewhat related problem with the 500 error issue I was posting about earlier today.

I originally placed these below zen cart recommended directives in my conf.d config file for a site/domain that I am installing the newest version of Zen-Cart – php based shopping cart. The developers claim that this file should be left as is, if I am to receive the protections that their new .htaccess files provide for their php scripts:

<Directory "/home/webspace/www/catalog/includes/">
AllowOverride Limit Options Indexes
</Directory>

<Directory "/home/webspace/www/catalog/zc_install/">
AllowOverride Limit Options Indexes
</Directory>

deny *everything*

<FilesMatch ".*">
Order Allow,Deny
Deny from all
</FilesMatch>

<FilesMatch ".*\.(js|JS|css|CSS|jpg|JPG|gif|GIF|png|PNG|swf|SWF)$">
Order Allow,Deny
Allow from all
</FilesMatch>

IndexIgnore */*

DirectoryIndex index.php

<FilesMatch ".*\..*">
Order Allow,Deny
Deny from all
</FilesMatch>

<FilesMatch "(^$|^favicon.ico$|.*\.(php|js|css|jpg|gif|png|html)$)">
Order Allow,Deny
Allow from all
</FilesMatch>

IndexIgnore */*

However, upon restart, Apache did not like the deny *everything* line and Apache would not restart, so I took that one line out, restarted httpd, and the server restarted fine.

Only problem is, the developer is now claiming that by taking that one line out, that I may as well take the entire directive set that they recommend out of my conf.d config file for this domain, because that one line if removed, disables all the protections provided in their new .htaccess files that came with Zen Cart. Funny though, I could not get his install scripts to run without all the rest of the directives I left in.

So anyway he claims that there is a way to configure my Apache 2.2.3 server which would make use of the deny *everything* line in my conf.d file and provide full protection. So I am now wondering what I need to do to set the switch to enable Apache to use this line and provide full protection. Something in the main httpd.conf file?

He claims that this is out of the scope of their support arena, the server settings that utilize his above suggested (actually required for install) directives.

Thanks for any advice here.

Comments

Re: Revisited: 500 internal server error, new prob

By Rich Bowen at 09/03/2010 - 16:11

If someone is telling you that "deny *everything*" is valid Apache
httpd syntax, you can rest assured that they don't know what they're
talking about, and you might want to find support elsewhere.

Additionally, <Directory> blocks are not permitted in .htaccess files.

I would strongly encourage you to point this "developer" here, as they
might benefit from our help.

Meanwhile, I would encourage you to read these:

<a href="http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#deny" title="http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#deny">http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#deny</a>
<a href="http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#allow" title="http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#allow">http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#allow</a>

Re: Revisited: 500 internal server error, new prob

By J Wilson at 09/03/2010 - 17:20

Actually I may have mis understood what he was trying to say in the ZC forum.

This is what one of the Zen Cart .htaccess file states:

# @copyright Copyright 2003-2010 Zen Cart Development Team
# @license <a href="http://www.zen-cart.com/license/2_0.txt" title="http://www.zen-cart.com/license/2_0.txt">http://www.zen-cart.com/license/2_0.txt</a> GNU Public License V2.0
# @version $Id: .htaccess 16111 2010-04-29 22:39:02Z drbyte $
#
# This is used with Apache WebServers
#
# The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions
# It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.
# Will also prevent people from seeing what is in the dir. and any sub-directories
#
# For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.
# Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.
# Example:
#<Directory "/usr/local/apache/htdocs">
# AllowOverride Limit Options Indexes
#</Directory>
###############################

# deny *everything*
<FilesMatch ".*">
Order Allow,Deny
Deny from all
</FilesMatch>

# but now allow just *certain* necessary files:
<FilesMatch ".*\.(js|JS|css|CSS|jpg|JPG|gif|GIF|png|PNG|swf|SWF)$">
Order Allow,Deny
Allow from all
</FilesMatch>

IndexIgnore */*

## NOTE: If you want even greater security to prevent hackers from running scripts in this folder, uncomment the following line (if your hosting company will allow you to use OPTIONS):
# OPTIONS -Indexes -ExecCGI

And this is what the readme docs for the new Zen Cart version states:

For added security, Zen Cart™ comes with several .htaccess files already included in various folders to help provide protection against unwanted visitors and even against mis-use of your site in the unfortunate situation of your site being hacked. These protections prevent hackers from using your site as phishing sources.
However, for these built-in protections to work, your web hosting server administrator MUST set the AllowOverride directive in the server's apache configuration (the server's master httpd.conf file) to "All" or at least ensure it includes these parameters: 'Limit Indexes'.

ie: AllowOverride All

or: AllowOverride Limit Indexes

(NOTE: You must also add "Options" if uncommenting OPTIONS directives in your .htaccess files)

Without these settings, you will likely encounter "500 Internal Server Error" messages when attempting to access various parts of your site, including perhaps the zc_install installer script.
Storeowners hosting on Windows Servers using IIS instead of Apache may need to remove the .htaccess files and rework them into suitable equivalents within your IIS configuration. See Microsoft's IIS website for specific assistance.

So from what I am understanding now, all I need to do is to edit httpd.conf and add in the block:

ie: AllowOverride All

or: AllowOverride Limit Indexes

and not add any entries into my conf.d apache config files for the domain(s) in question?

I was thinking that I should substitute <Directory "/usr/local/apache/htdocs"> with the path of the domain that owns that web space and put the directives in all my individual apache config files for those domains running a store, which I did.

Now it appears that they are to be left in the .htaccess file and I just edit the main httpd.conf file. Do you get this impression as well?

Re: Revisited: 500 internal server error, new prob

By Frank Gingras at 09/03/2010 - 17:21

On 03/09/2010 5:20 PM, J Wilson wrote:
A leading # indicates a comment. Be careful to replicate the configuration lines *exactly* as they
are given to you.

Frank

Re: Revisited: 500 internal server error, new prob

By J Wilson at 09/03/2010 - 17:29

OK thanks I realize that now the way he worded it in the forum I thought it was to be part of the apache directives and not a comment and thought I should remove the # sign.

So does it appear that all I need to do is edit the main httpd.conf file and enter in

ie: AllowOverride All

or: AllowOverride Limit Indexes

into httpd.conf?

Re: Revisited: 500 internal server error, new prob

By Rich Bowen at 09/04/2010 - 07:35

Which one of those you use depends on what you're trying to do. Read
the AllowOverride docs, and decide which you wish to prefer. In a
security-sensitive application like a shopping cart, you want to allow
as little as possible.

Re: Revisited: 500 internal server error, new prob

By Frank Gingras at 09/03/2010 - 15:54

On 03/09/2010 3:50 PM, J Wilson wrote:
Hello,

*everything* is not a valid argument for the Deny directive. Please consult the official
documentation for proper usage.

Having said that, I believe that this line should be a comment to begin with, since the FilesMatch
block that follows WILL deny all requests.

Frank