[PHP] protect your CSS files, and possibly other extenstions as well...

[Kit DeKat]

I recently discovered a php method to hide text-based files from remote
users while allowing access to your internal pages and scripts. You can
take advantage of this technique as well to protect your artistic rights:
There are two variants: one for php scriptss and their included counterparts
and another for 'stand-alone' files that are refered to within your own html
-- such as *.css and *.js that can be link'd or src'd via html tags
--
PHP SCRIPTs:
master pages: (index.php, gallery.php, ...)

included pages: (header.php, menu.php, ...)

'include_path/check_constant.inc':

   /*
* PHP Internal Inclusion Verification v1.0
    * Author: Tim Maynard, aka: Kit DeKat (kitdekat) (c)09-MAY-2005
* E-mail: [EMAIL PROTECTED]
*/
   $const = get_defined_constants();
   if( !isset($const["SOME_CONSTANT"]) ||
   ($const["SOME_CONSTANT"] != 'secret_string') )
   {
   header('Status: 404 Not Found');
   header('HTTP/1.1 404 Not Found');
   // the following is my path to the standard Apache2 error 
documents which
   // i feel that the standard docs are the best to hide that fact 
that the
   // file was ever there, versus a custom error implying you're 
covering it
   
readfile('http://'.$_SERVER["SERVER_NAME"].'/error/HTTP_NOT_FOUND.html.var');
   exit();
   }
?>

--
This should hide all the includes, configs, etc.. files that you have 
lying around.
I should hope that you already have the following somewhere in your 
http.conf
file to protect from direct-remote downloads -- this snippet will 
protect against
files ending in '.inc' and '.inc.php', modify to suit your site:


   Order allow,deny
   Deny from all
   Satisfy All

--
CSS and JS files:
First, you will need to tell php to parse these files, which can be done 
again by
editing your httpd.conf files to add the extensions desired to the php list:

AddType application/x-httpd-php .php .phtml .php3 .css .js
You will take a performance hit for adding the parser to more pages, but
I think its worth the gain in security and your general sanity and 
well-being.
now that php is parsing these files, add the following to the top of each:


   /*
* PHP Internal Inclusion Verification v1.0
* Author: Tim Maynard, aka: Kit DeKat (kitdekat) (c)09-MAY-2005
* E-mail: [EMAIL PROTECTED]
*/
   if( !isset( $_SERVER["HTTP_REFERER"]) ||
   !strpos($_SERVER["HTTP_REFERER"],$_SERVER["SERVER_NAME"]) )
   {
   header('Status: 404 Not Found');
   header('HTTP/1.1 404 Not Found');
   
readfile('http://'.$_SERVER["SERVER_NAME"].'/error/HTTP_NOT_FOUND.html.var');
   exit();
   }
?>

This is very similar code to the php-scripts, but the change is that it 
is not looking for
the constant anymore (since that doesn't exist once the page is in hte 
browser), but
makes sure that the server calling the file is itself and not a remote 
call from an address bar.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] protect your CSS files, and possibly other extenstions as well...

[Kit DeKat]

Richard Lynch wrote:
You could do all this...
Or you could just move the files outside your web tree and change your
include path.  [shrug]
 

This is probably true, but I was thinking of a virtual hosting 
environment where its easier to maintain the code when its all in a 
sub-directory named by the address. But even then I guess you can make 
the document root one below the virtual host root and then place 
includes next to the document root to keep them grouped together, yet 
seperated.

   if( !isset( $_SERVER["HTTP_REFERER"]) ||
   !strpos($_SERVER["HTTP_REFERER"],$_SERVER["SERVER_NAME"]) )
   

I don't think you can count on HTTP_REFERER to be set by browsers.
It's not required by the HTTP spec, as I understand it.
Plus, it seems to me like you are asking for trouble between
www.example.com and example.com if they surf to www. but your
developer/designer only uses 'example.com'
I also would wonder if this will scale up to server farms?  Maybe the
REFERER/SERVER_NAME stuff is all hunky-dory consistent there...
 

I tested the HTTP_REFERER in both IE v6 and FireFox v1 and the code is 
working. I dont have an IE v5.x to test on or I would've verified that 
as well. the SERVER_NAME string will be equal to www.example.com or just 
example.com, whichever was used to access the site -- it is pulled from 
between the http:// and the next / so it will allow access to only a 
self referring server call.

As for server farms, the SERVRE_NAME part will have to be modified to 
include every allowable server that can refer to it.

If an end user wants to read your CSS or JS bad enough, they can get it.
Nor is this really a problem.
 

There have been incidents in the past when another website stripped an 
artists site entirely; html, css, js, images, everything. This code will 
prevent css and js from being directly downloaded from a web browser. 
This will work as long as you dont have another service accessing the 
directories, such as ftp that bypasses the web server parsing routine.

The following two methods for linking to stylesheets was used in testing:

and

@import('http:///styles.css');

You definitely do *NOT* want them able to surf to non-entry (ie,
'include'd) files!
Your developers (you) almost certainly spent zero time wondering "what if"
the user did that, and them executing your .php/.inc/.inc.php file out of
context could wreak havoc.
That is the whole intention of this exercise, to prevent direct user 
access to included
files both templated and configuration files. As mentioned earlier, my 
intention was on
virtual host directories that keep all the files under on roof. This 
method for hiding php
scripts is already used widely in many php-portal kits that keep 
everything in one directory
for ease of install for end-users.

My ammendum for css and js files prevents nosey ripoffs away from an 
original designers
work. They spent a lot of time in these designs and dont want random joe 
to just copy it for
self-serving purposes. Even if they have all the html, they will have to 
spend some time trying
to figure out the styles and javascript calls to match your sites look 
and feel. I dont think the
majority of the ripoff artists will spend that time, and they will move 
on to someone else.

There are many "solutions" for this -- But to me, moving the files out of
the web tree and setting include_path makes the most sense as the safest.
There's *NO* *WAY* you're gonna screw up your httpd.conf or .htaccess
files and make the files not in the web tree suddenly accessible.
It's not like setting include_path is rocket science once you figure out
that this is EXACTLY what that is for.
Just my opinion.
As mention earlier I will look into the shuffling of directories and 
modification of the include_path
for hiding included files and see what modifications are needed for the 
code then.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php