Jump to content
Sign in to follow this  
Greecom

Kiss

Recommended Posts

Hi Robert

I have question its looks like is go to be released osCommerce 2.3 is go to be all your nice contributions compatible with the new 2.3 osCommerce ULTIMATE Seo Urls 5 - by FWR Media, KISS FileSafe, KissER Error Handling & Debugging, KissMT Dynamic SEO Meta & Canonical Header Tags?

OSCOM v2.3 Pre-Release Notes

 

Thank you

Share this post


Link to post
Share on other sites

Hi Robert

I have question its looks like is go to be released osCommerce 2.3 is go to be all your nice contributions compatible with the new 2.3 osCommerce ULTIMATE Seo Urls 5 - by FWR Media, KISS FileSafe, KissER Error Handling & Debugging, KissMT Dynamic SEO Meta & Canonical Header Tags?

OSCOM v2.3 Pre-Release Notes

 

Thank you

 

Yes they will all be compatible.

Share this post


Link to post
Share on other sites

Hi Robert,

 

RE: KISS_FileSafe_version_1.0_r12 7564

 

I added the .htaccess file to cache directory as recommended

then browsed to it and received this:

 

500 - Internal Server Error

This is a temporary server error.

Please try to reload the webpage later.

 

If you are the webmaster of this site please log in to Cpanel and check the Error Logs. You will find the exact reason for this error there.

 

Common reasons for this error are:

 

* Incorrect file/directory permissions: Above 755. In order files to be processed by the webserver, their permissions have to be equal or below 755. You can update file permissions with a FTP client or through cPanel's File Manager.

* Incorrect Apache directives inside .htaccess file. Make sure you have not specified unsupported directives inside the local .htaccess file. Such include PHP settings and Apache module settings.

 

------------ end -----------------

 

Is this the correct behavior for the .htaccess code:

php_flag engine off

<Files ~ "\.(php*|s?p?html|cgi|pl|ini)$">

deny from all

</Files>

 

You really make installation a breeze by the way,

 

Thanks for your support,

 

jk

Share this post


Link to post
Share on other sites

Hi Robert,

 

RE: KISS_FileSafe_version_1.0_r12 7564

 

I added the .htaccess file to cache directory as recommended

then browsed to it and received this:

 

500 - Internal Server Error

This is a temporary server error.

Please try to reload the webpage later.

 

If you are the webmaster of this site please log in to Cpanel and check the Error Logs. You will find the exact reason for this error there.

 

Common reasons for this error are:

 

* Incorrect file/directory permissions: Above 755. In order files to be processed by the webserver, their permissions have to be equal or below 755. You can update file permissions with a FTP client or through cPanel's File Manager.

* Incorrect Apache directives inside .htaccess file. Make sure you have not specified unsupported directives inside the local .htaccess file. Such include PHP settings and Apache module settings.

 

------------ end -----------------

 

Is this the correct behavior for the .htaccess code:

php_flag engine off

<Files ~ "\.(php*|s?p?html|cgi|pl|ini){:content:}quot;>

deny from all

</Files>

 

You really make installation a breeze by the way,

 

Thanks for your support,

 

jk

 

No .. I would expect something like ..

Forbidden

 

You don't have permission to access /[PATH]/images/test.php on this server.

 

Perhaps your server doesn't allow rules in .htaccess.

Edited by FWR Media

Share this post


Link to post
Share on other sites

No .. I would expect something like ..

 

 

Perhaps your server doesn't allow rules in .htaccess.

 

 

Hi Robert. Thanks for your reply.

After googling and trying different modifications,

what did elicit a 403 response was commenting out

# php_flag engine off

<Files ~ "\.(php*|s?p?html|cgi|pl|ini)$">

deny from all

</Files>

 

Also contacted the hosting help desk who replied:

Thank you for contacting our Support Team.

 

Please delete the following code from the .htaccess file:

 

php_flag engine off

 

After that save the file and the issue should be resolved.

-------- end -------------

 

1. What functionality is sacrificed when php_flag engine off is not executed?

 

2. If php_flag engine had been set to off, does it need to later be set to on?

 

Thanks for all your invaluable input.

 

jk

Share this post


Link to post
Share on other sites

Hi Robert. Thanks for your reply.

After googling and trying different modifications,

what did elicit a 403 response was commenting out

# php_flag engine off

<Files ~ "\.(php*|s?p?html|cgi|pl|ini){:content:}quot;>

deny from all

</Files>

 

Also contacted the hosting help desk who replied:

Thank you for contacting our Support Team.

 

Please delete the following code from the .htaccess file:

 

php_flag engine off

 

After that save the file and the issue should be resolved.

-------- end -------------

 

1. What functionality is sacrificed when php_flag engine off is not executed?

 

2. If php_flag engine had been set to off, does it need to later be set to on?

 

Thanks for all your invaluable input.

 

jk

 

It is a security measure, turning off the php engine in writeable directories stops php files from being executed.

 

What your host has done is say "lower your security" and haven't even bothered to warn you.

Share this post


Link to post
Share on other sites

It is a security measure, turning off the php engine in writeable directories stops php files from being executed.

 

What your host has done is say "lower your security" and haven't even bothered to warn you.

 

Thank you for pointing this out. I re-contacted them and they suggested putting a php.ini file into each writable directory.

So I put a php.ini:

ini_set('php_flag engine', 'off');

into the cache directory

 

Browsed to it and got the 403 Forbidden (which I also got without the php.ini)

just not certain:

1. ini_set('php_flag engine', 'off');

Is the correct directive?

 

2. Does it need to be turned back ON elsewhere?

 

Thanks for your expert assistance,

jk

Share this post


Link to post
Share on other sites

 

hmmm apparently

ini_set('php_flag engine', 'off');

Is NOT a directive at all (according to the hosting rep)

so it probably makes both earlier questions moot

 

What he recommended was use different command/s.:

"For example you can use a local .htaccess file with directives like the below ones:

 

# disable all CGI here

Options -ExecCGI

AddHandler text/html .php

AddHandler text/html .cgi

AddHandler text/html .pl

AddHandler text/html .htm

AddHandler text/html .html

AddHandler text/html .shtml

----- end quote -------

 

Hopefully this is a different route (from php_flag engine off) to the same destination.

 

Thanks for bearing with me during this period of uncertainty,

jk

Share this post


Link to post
Share on other sites

hmmm apparently

ini_set('php_flag engine', 'off');

Is NOT a directive at all (according to the hosting rep)

so it probably makes both earlier questions moot

 

What he recommended was use different command/s.:

"For example you can use a local .htaccess file with directives like the below ones:

 

# disable all CGI here

Options -ExecCGI

AddHandler text/html .php

AddHandler text/html .cgi

AddHandler text/html .pl

AddHandler text/html .htm

AddHandler text/html .html

AddHandler text/html .shtml

----- end quote -------

 

Hopefully this is a different route (from php_flag engine off) to the same destination.

 

Thanks for bearing with me during this period of uncertainty,

jk

 

No

 

ini_set('php_flag engine', 'off');

 

is rubbish.

Share this post


Link to post
Share on other sites

No

 

ini_set('php_flag engine', 'off');

 

is rubbish.

 

in lieu of php_flag engine off

The hosting rep suggested using different command/s.:

"For example you can use a local .htaccess file with directives like the below ones:

 

# disable all CGI here

Options -ExecCGI

AddHandler text/html .php

AddHandler text/html .cgi

AddHandler text/html .pl

AddHandler text/html .htm

AddHandler text/html .html

AddHandler text/html .shtml

----- end quote -------

 

Hopefully that is a different route (from php_flag engine off) to the same destination.

 

Would you put a stamp of approval on that recommendation?

 

Thanks for your inimitable insight,

jk

Share this post


Link to post
Share on other sites

in lieu of php_flag engine off

The hosting rep suggested using different command/s.:

"For example you can use a local .htaccess file with directives like the below ones:

 

# disable all CGI here

Options -ExecCGI

AddHandler text/html .php

AddHandler text/html .cgi

AddHandler text/html .pl

AddHandler text/html .htm

AddHandler text/html .html

AddHandler text/html .shtml

----- end quote -------

 

Hopefully that is a different route (from php_flag engine off) to the same destination.

 

Would you put a stamp of approval on that recommendation?

 

Thanks for your inimitable insight,

jk

 

Well if PHP is built as a CGI rather than a CLI program then those rules will exclude the execution of files with those extensions.

 

Turning the PHP engine off and excluding files with a .php extension however are different.

 

Check with your hosts but I thought you could just include

 

engine = off

 

In a php.ini file if running as a CGI.

Edited by FWR Media

Share this post


Link to post
Share on other sites

Well if PHP is built as a CGI rather than a CLI program then those rules will exclude the execution of files with those extensions.

 

Turning the PHP engine off and excluding files with a .php extension however are different.

 

Check with your hosts but I thought you could just include

 

engine = off

 

In a php.ini file if running as a CGI.

 

Thank you, Robert, for that thought provoking answer,

in fact,

I'm struggling diligently, translating it into my native language

(something called english)

to say your answer was a little over my head would be akin

to saying the ocean is slightly damp

and yet... I sense the urgent prudence of minimizing "exposure"

within writable directories as an integral part of any strategic defense,

to be candid, I was under the impression that 403 Forbidden was ample

to thwart any unwelcome stunts, that's where I'm stumbling,

Is turning the engine off because it's possible to penetrate beyond 403 Forbidden?

Sorry if this post appears to be anything but genuine admiration for your guidance.

 

jk

Share this post


Link to post
Share on other sites

Thank you, Robert, for that thought provoking answer,

in fact,

I'm struggling diligently, translating it into my native language

(something called english)

to say your answer was a little over my head would be akin

to saying the ocean is slightly damp

and yet... I sense the urgent prudence of minimizing "exposure"

within writable directories as an integral part of any strategic defense,

to be candid, I was under the impression that 403 Forbidden was ample

to thwart any unwelcome stunts, that's where I'm stumbling,

Is turning the engine off because it's possible to penetrate beyond 403 Forbidden?

Sorry if this post appears to be anything but genuine admiration for your guidance.

 

jk

 

The problem is that adding specific file extensions to a banned list is a blacklist approach.

 

Blacklist approaches rarely work when trying to stop hackers and the huge range of hacking vectors.

Some examples of php extensions are .php3, .php4, .php5 etc etc.

 

But turning the engine off PHP simply doesn't work in that directory regardless of the file extension.

 

My view with writeable directories ( especially on shared servers ) is ..

 

Do I intend to parse files in this directory via PHP?

 

Answer no .. Turn the engine off.

Edited by FWR Media

Share this post


Link to post
Share on other sites

The problem is that adding specific file extensions to a banned list is a blacklist approach.

 

Blacklist approaches rarely work when trying to stop hackers and the huge range of hacking vectors.

Some examples of php extensions are .php3, .php4, .php5 etc etc.

 

But turning the engine off PHP simply doesn't work in that directory regardless of the file extension.

 

My view with writeable directories ( especially on shared servers ) is ..

 

Do I intend to parse files in this directory via PHP?

 

Answer no .. Turn the engine off.

 

I'm immensely grateful for your considerate and thoughtful explanation.

At the same time, I'm reminded of that line from an old western

where one cowboy turns to the other and drawls,

"You know, Clem, you're like an owl,

the more light is shined on something, the less you see".

(In this scene, I'm Clem)

For the sake of expedience and distillation,

Here is how I "see" it:

 

Multi-Phase Objective:

Allow the site to be toured, while monitoring/restricting access to sensitive areas/preventing vandalism/discouraging theft, bugging, redirection, offensive conduct, in general, behaving in any manner deemed dishonorable/unethical/low down varmints

 

htaccess Strategy: in writable directories

Install htaccess 403 Forbidden (a No Trespassing sign?)

that must be fortified with two additional supplements

to wit, your inclusion of additional code in the htaccess:

 

1. php_flag engine off

2. <Files ~ "\.(php*|s?p?html|cgi|pl|ini)$">

deny from all

</Files>

 

So now, I'm drawing the conclusion that somehow,

like a No Trespassing sign,

403 Forbidden alone is insufficient to deter the determined

 

OK, maybe I shouldn't underestimate the resourcefulness of

those hellbent on havoc and further buttress the writable directories by

 

disabling the php engine:

php_flag engine off

 

as well as, making certain file extensions inaccessible/tamperproof:

<Files ~ "\.(php*|s?p?html|cgi|pl|ini)$">

This seems like not only do we turn the php engine off,

we also "unplug" php*|s from the receptacle, so to speak

 

Am I on the right track with this synopsis of the htaccess's additional dual purpose?

 

Then, in a desperate googling effort to find some answers on my own, I came across this,

"Note that when PHP is disabled then the end user will get the source code of the PHP script in their browser."

Which strikes me as being analogous to protecting the secret of how to make a bomb

by putting it on public display behind bulletproof glass (or am I just being shy)

 

Suddenly, I realize it's disrespectful and lazy of me to keep bothering you

when I should be familiarizing myself

with the information you've already painstakingly provided,

except for one last question,

 

How would someone add you to their Christmas List?

 

jk

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×