I want to add this to the hcaccess file, but it's not there, where the tutorial says

[JDog21]

I am slowly trying to beef up security measures to my site, as I load products.

I'd like to be able to block general hack attempts. I've already changed the name of my admin folder, and now I want to do the following (from a tutorial):
-------

This should go in the .htaccess file located in the root of your Zen Cart site folder. ie: the same folder in which you find ipn_main_handler.php and index.php and page_not_found.php.

# redirects any URL that includes: record_company.php/password_forgotten.php
RedirectMatch Permanent ^/(.*[record_company.php]+)/(password_forgotten.php)$ /page_not_found.php

# redirects any URL that includes: /images/wp- with 'wp-' being anything that ends with '.php'
# this allows for images named such as 'wp-header.jpg' to work
RedirectMatch Permanent ^/(.*[images]+)/(wp-.*\.php)$ /page_not_found.php

NOTE: If your store's files are located in another folder, add that folder in the /page_not_found.php (both places)

---------------
Simple. I copy the code, paste it in my htaccess file (the one located in my root directory, as described).

Only 1 problem. There is NO htaccess file in the root directory where the other two specified files are located. The tutorial says to add to the htaccess file located there; not create one. So, why the apparent error?
Also, if I plan to upgrade to 1.3.9, is this a moot point, since all the security patches should already be there, or is this a separate enhancement?

Comments?

[DrByte]

1. Correct, there is no .htaccess in the "root" of the site by default. You can simply create one if desired.

2. While 1.3.9 doesn't have that code in a supplied .htaccess, it does have protection against the old vulnerability so attempts to attack will be thwarted by the fixed code.
But, adding it in an .htaccess anyway will allow Apache to divert such attackers before ZC even has to use its built-in protections.

[g1smd]

I want to do the following (from a tutorial).

# redirects any URL that includes: record_company.php/password_forgotten.php
RedirectMatch Permanent ^/(.*[record_company.php]+)/(password_forgotten.php)$ /page_not_found.php

That's quite a dodgy tutorial you've found.

The pattern [record_company.php]+ will match URL requests containing:
rcrdcmpyhhpp
rrrrrrrrrrdddddd
compcompcompyyyycomp
and an infinite number of other requests which contain any of the letters "r e c o d m p a n y h" and/or an underscore and/or period.

The leading .* pattern also has the effect of the pattern matching "anything of any length, or nothing" as a prefix to that. This means that mod_rewrite will make several thousand "back off and retry" attempts at pattern matching for every URL request handled by your server.

When you consider that a single page might have several dozen elements (images, CSS, JS, etc), this code is almost a self-inflicted denial of service for all of your visitors.

# redirects any URL that includes: /images/wp- with 'wp-' being anything that ends with '.php'
# this allows for images named such as 'wp-header.jpg' to work
RedirectMatch Permanent ^/(.*[images]+)/(wp-.*\.php)$ /page_not_found.php

This code has the same problem.

The pattern [images]+ allows any URL request containing the letters "i m a g e s" in any order and any amount, and the preceding .* pattern again causes the rule to try thousands of "back of and retry" pattern matching attempts for each requested URL. The second .* pattern multiplies the number "back off and retry" attempts to an even greater amount, slowing the server yet more.

So, a request containing zzzz56789/3edt5t/eeeegggggimimimim/wp-bbbbbb.php will eventually match the rule after very many pattern matching attempts, instead of immediately triggering a 404 response after one try.

Once a match has been found, there's a second fatal flaw. This code does not return a 404 response. It returns a 301 redirect to a new URL. The browser then has to make a new HTTP request for the new URL, the pattern matching runs again (and this time fails) and then a page is brought up with the "Not Found" error message. This page is likely displayed with "200 OK" status, as it has been directly requested by the browser as a new URL instead of being returned by Apache's internal ErrorDocument handling.

You likely can't see the bad effects of what is going on inside your server, because all those attempts do eventually bring up an error message. Look again using Live HTTP Headers for Firefox and you'll immediately see the problems.

This code is likely to force many users into an early server upgrade as it is very very inefficient. It could also be harmful to search rankings if external sites maliciously mass-linked to certain "invented" path-part patterns as if they were real URLs supposedly active on your site. It is links that define URLs. It's up to the server to return the correct HTTP status code for those requests.

This code does not do so, has many dangerous (to the wellbeing of your site) elements and should not be used in its present form.

[Website Rob]

Although everyone is at different levels of knowledge an experience, most people on the Forum are looking for something that works -- even a little bit as that is usually more than what they had before -- and can be copied and pasted.

It is easy to pick apart what others have provided as there are usually faults with most code; some of which has been created specifically for a site or purpose. What is difficult is to provide an alternative. I wonder what alternative coding could be suggested in this case?

[g1smd]

copied and pasted.

This is server configuration code and it is rare that a solution can be a simple copy and paste job and still fit all scenarios. Always be careful when copying code. Make sure it does everything you need it to do.

It is easy to pick apart what others have provided as there are usually faults with most code; some of which has been created specifically for a site or purpose.

This code is different. It is suicidally faulty in multiple ways.

What is difficult is to provide an alternative. I wonder what alternative coding could be suggested in this case?

Requirements vague, as exactly how deep the folder structure is here, wasn't mentioned. This will work at any folder depth. Not tested, ensure it does exactly what you need it to do:

# Fails with 404 error, any URL request that includes
# record_company.php/password_forgotten.php
# at any folder depth or root.
RewriteRule ^([^/]+/)*record_company\.php/password_forgotten\.php$ /page-does-not-exist [L]

# Fails with 404 error, any URL request that includes
# images/wp- with 'wp-' being anything that ends with '.php'
# this allows for images named such as 'wp-header.jpg' to work
RewriteRule ^([^/]+/)*images/wp-[^.]+\.php$ /page-does-not-exist [L]

The literal /page-does-not-exist rewrite will cause Apache to serve the 404 ErrorDocument through the standard internal mechanism, and correctly deliver the 404 HTTP status code in the HTTP header. Other methods run the danger of the error page being returned with either 200 or chained 302=>200 HTTP status. Both of those scenarios must be avoided.

[JDog21]

So, I can either just upgrade and not worry about it, or I can upgrade AND add this:

1) First, I make an htaccess file for the root directory

2) then I put this code in that new file:

# Fails with 404 error, any URL request that includes
# record_company.php/password_forgotten.php
# at any folder depth or root.
RewriteRule ^([^/]+/)*record_company\.php/password_forgotten\.php$ /page-does-not-exist [L]

# Fails with 404 error, any URL request that includes
# images/wp- with 'wp-' being anything that ends with '.php'
# this allows for images named such as 'wp-header.jpg' to work
RewriteRule ^([^/]+/)*images/wp-[^.]+\.php$ /page-does-not-exist [L]

This above will enhance security, regarding most script-kiddy attacks, as well as most other hackers, correct?

[JDog21]

I made an .htaccess file and put the above noted code in it.

I tried to go to my site, and got a 500 internal service error.

[DrByte]

You probably need to add "RewriteEngine On" to the top of the file (on its own new line, without quotation marks).

Your apache error_log should tell you why exactly you're seeing the 500 error.

[JDog21]

I can't access my apache error log. My server people say I have to wait 24 hours after I have "enabled" the error logs.

But the htaccess file, as written below, doesn't work:

ReWriteEngine on
# Fails with 404 error, any URL request that includes
# record_company.php/password_forgotten.php
# at any folder depth or root.
RewriteRule ^([^/]+/)*record_company\.php/password_forgotten\.php$ /page-does-not-exist [L]

# Fails with 404 error, any URL request that includes
# images/wp- with 'wp-' being anything that ends with '.php'
# this allows for images named such as 'wp-header.jpg' to work
RewriteRule ^([^/]+/)*images/wp-[^.]+\.php$ /page-does-not-exist [L]

Additionally, I tried to update to the 1.3.9 version of ZC, at my server. My server (Godaddy) says that version is not available as of yet (I did, however, get 1.3.8a). I am tempted to download 1.3.9 and put it on my server. Is this version still a beta version? Should I go ahead and put it on? I want to do so.

Irrespective of that, I would like to get the .htaccess file to work... Can you venture a guess as to why it's not working, or should I wait 24 hours and give you the info. first? I intend to put every known security enhancement into play......

[DrByte]

1. You should ALWAYS do manual upgrades. Don't ever trust so-called "automated" upgraders. Especially don't trust GoDaddy (but that's another story ... more on that in hundreds of other forum discussions).

2. Yes, do your own upgrade to 1.3.9

3. Deal with this particular .htaccess issue later. It's moot with 1.3.9 installed anyway.
g1smd did say it was untested code ... perhaps he'll offer a working tested version for you.
Your problem *may* be unique to your server config.