Processing php directives in .html files on the ccgi server
Hello,
I've got various webpages working on my ccgi server, and the php scripting in them works great. However, I've had to call all my files index.php etc instead of index.html.
According to various websites, I can rename my files back to <page>.html instead of <page>.php, and still get php scripting working in them if I modify my .htaccess file to include lines such as these:
RemoveHandler .html .htm
AddType application/x-httpd-php .php .htm .html
or
AddHandler application/x-httpd-php .html .htm
or, according to 1-to-1's support, for their web pages:
AddType x-mapp-php4 .html .htm
I can't get any of these to work with my plus.net ccgi server though! Am I missing the correct incantation to do this with plus.net? I realise I could hack around the problem with using mod_rewrite instead, but that seems pretty unattractive.
Thanks for any advice! Much appreciated.
I've got various webpages working on my ccgi server, and the php scripting in them works great. However, I've had to call all my files index.php etc instead of index.html.
According to various websites, I can rename my files back to <page>.html instead of <page>.php, and still get php scripting working in them if I modify my .htaccess file to include lines such as these:
AddType application/x-httpd-php .php .htm .html
or
or, according to 1-to-1's support, for their web pages:
I can't get any of these to work with my plus.net ccgi server though! Am I missing the correct incantation to do this with plus.net? I realise I could hack around the problem with using mod_rewrite instead, but that seems pretty unattractive.
Thanks for any advice! Much appreciated.
Hey, guess what.
index.php is in fact one of the default files that's served up when just a directory is specified in the url. So reason number 2 on my list doesn't apply at all.
I think I'll just get over reason number 1 and rename all my files to .php.
Looks like you did manage to help after all, Mr Penguin.
index.php is in fact one of the default files that's served up when just a directory is specified in the url. So reason number 2 on my list doesn't apply at all.
I think I'll just get over reason number 1 and rename all my files to .php.
Looks like you did manage to help after all, Mr Penguin.
Hey there,
This will be a Long post, I'll try to make it as clear as possible.
I could understand masking the initial File Extension for fear of PHP type exploits and security risks...
BUT there comes two problems.
The First is ... The way Apache and PHP handel the HTTP Response.
No matter how much you try masking it using that method, you'll always find two Header Responses like this:
Which is read by the Browser / Socket Layer - maybe even tossed a-side as it's a pointless header in terms of the Browser Output anyway...
This can be read by any Network Interface Sniffing software, any attacker worth their salt would know instantatly and can access the Protocol Layer Transport using a Sniffer - they're dead easy to use...
From a security point of view it's not strong, but deters the obvious reference - aka those who do not know their HTTP
so yes in a sense it's an effective deceptor.
Those who might know a bit would then still see the fact that a ".html" is being processed by PHP (CGI/Module) and can guess that it is using a ".htaccess" file to direct the processing of the page, because it's an Apache Server - in the case of the CCGI Platform, I do not know of any other HTTP Server which allows an equivilant to ".htaccess".
This then leads to the the Second problem,
That established, if you then use a boxed OpenSource Content Management System or any Pre-written Scripts or other OpenSoruce,
it's liable for security issues because the attacker doesn't always have to work blind, they would have full source referenced by Credits, Source Output structure and Format... and so forth and can find potentual exploits in no time.
Which really only applies to some, it just depends what that maybe running a Web Business and those who are running a well known Web site that is in Search Engines and holds Meta Phrases relating to the Scripts used - proving more problems security wise, when you could possibly Google the Exploitable script in question and stuble upon your website.
As it is it doesn't really appear to make an odds from what I see on your Website but another user might find this useful (maybe).
As Peter Says,
The "Average user" wouldn't have the foggiest.
*Sorry if I've bored everyone into submission on the Subject,
I just thought it might help as a relevant bit of a knowledge filler*
Jim,
This will be a Long post, I'll try to make it as clear as possible.
I could understand masking the initial File Extension for fear of PHP type exploits and security risks...
BUT there comes two problems.
The First is ... The way Apache and PHP handel the HTTP Response.
No matter how much you try masking it using that method, you'll always find two Header Responses like this:
Server: Apache
X-Powered-By: PHP/x.x.x
Which is read by the Browser / Socket Layer - maybe even tossed a-side as it's a pointless header in terms of the Browser Output anyway...
This can be read by any Network Interface Sniffing software, any attacker worth their salt would know instantatly and can access the Protocol Layer Transport using a Sniffer - they're dead easy to use...
From a security point of view it's not strong, but deters the obvious reference - aka those who do not know their HTTP
so yes in a sense it's an effective deceptor.Those who might know a bit would then still see the fact that a ".html" is being processed by PHP (CGI/Module) and can guess that it is using a ".htaccess" file to direct the processing of the page, because it's an Apache Server - in the case of the CCGI Platform, I do not know of any other HTTP Server which allows an equivilant to ".htaccess".
This then leads to the the Second problem,
That established, if you then use a boxed OpenSource Content Management System or any Pre-written Scripts or other OpenSoruce,
it's liable for security issues because the attacker doesn't always have to work blind, they would have full source referenced by Credits, Source Output structure and Format... and so forth and can find potentual exploits in no time.
Which really only applies to some, it just depends what that maybe running a Web Business and those who are running a well known Web site that is in Search Engines and holds Meta Phrases relating to the Scripts used - proving more problems security wise, when you could possibly Google the Exploitable script in question and stuble upon your website.
As it is it doesn't really appear to make an odds from what I see on your Website but another user might find this useful (maybe).
As Peter Says,
The "Average user" wouldn't have the foggiest.
*Sorry if I've bored everyone into submission on the Subject,
I just thought it might help as a relevant bit of a knowledge filler*
Jim,