HTACCESS: My nightmare continues.
- *ROLLS EYES*, Ok, I am a geek. Why is it always those tiny things that catch you, while you develop a website. Google is my home away from home. Those of you who know me, realize how far I go to gather information. Most times I hit gold, some times I just hit dirt. Tonight, I found more dirt than gold. Eventually, if you continue to dig, you will get to the gold, but your arms get tired.
- I will be posting some quick helpful notes and some of those gold-links, which I have found to be an invaluable assistance in my temporary insanity. I never wanted to learn half of this stuff, now, I have no choice. Unfortunately, that leaves me with only one option. I must be a jack of all trades, master of none... again. Things would so so much smoother if I had a closer network of minds to brain-storm with.
- I have many friends who know this stuff, but the distance between thoughts is an unavoidable hurdle. Perhaps I may turn my eyes back towards some of the young and fresh minds, that plague the school-systems. Give them an ultimate project, a goal, offer some form, possible opportunity, in exchange for knowledge of real-world applications. I avoided programming and computer classes, because making goofy toys with no real function, that others had made previously, just didn't interest me.
MY TIPS:
- First, every .htaccess should have this...
#----------------------------------------#
Options All -Indexes
ServerSignature Off
RewriteEngine On
#----------------------------------------#
- In order, (Options ALL -Indexes) tells your server that you DO NOT want to show visitors your file DIR. This will stop your site from showing users a 'Windows-style' directory of files. Unless you have a directory full of TXT or MPG or MP3 or JPG. You don't want people browsing your site like it is a windows system folder.
- (ServerSignature Off) is a security issue. Your guests do not need to know that information about your server. This would show something like this, on an error page. {Apache/1.3.19 (UNIX) (Red-Hat/Linux) mod_ssl/2.8.1} This holds no relevance to the outside world, and you can get that information internally, if needed. Having it exposed, allows hackers and bots to KNOW the best way to defeat your system. Might as well let them guess, don't give them a door to knock on.
- (RewriteEngine On) tells your server that there are rewrite rules, if you do not have a global setting. It is not wise to use a global setting, unless your site is small, or it is structure with only a few folders. Each folder will cause your server to look for rewrite rules, adding seconds onto every page call. Most Rewrite rules are in the main folder, related to URL processing. However, due to my hotlinking protection, I also have folders with additional Rewrite rules.
Next, depending on your desires...
- You should place all 'NO ACCESS' rules first. No sense in checking other rules, if the file they want is something you are not willing to surrender. I have certain additional files protected. For instance, I have a special 'pp' file, which is just a PHP file, but one that only my server has rights to.
- My first level of protection is to place it inside a folder below ROOT/WWW, called an INCLUDE folder. You add it to your pages by a PHP command [include('myfile.pp');]. However, sometimes the files are not inside an INCLUDE folder. If a user typed the URL to that file, and if PHP was down/broken/hacked, it would show your PHP code as normal text. If you protect that file in .htaccess then even if PHP is down, they get nothing!
#----------------------------------------#
RewriteCond %{REQUEST_FILENAME} ^(.*)\.(pp|ini|htaccess|htpasswd|log)$ [NC]
RewriteRule ^(.*)\.(pp|ini|htaccess|htpasswd|log)$ - [F,L]
#----------------------------------------#
- The above code kills any request for a file that only the server should see. Telling them the file is forbidden. This goes hand-in-hand with your FileAccess permissions. Should you forget to set the proper permissions, this adds a nice backup. Like I said, it also stops further processing, where none is needed. No .htaccess commands below that point are run, if the file requested is... myfile.pp, myfile.ini, .htaccess, .htpassword, myserver.log.
Next, depending on your desires...
- You should go further to ensure that your PHP handled files are not going to show an ugly, 'No Input Specified'. This happens if you call a non-existent file, with a PHP handled extension, and there is nothing there to process. I have no clue how to turn that off, or if it can be turned off. All I know is that when I type, 'nonexistentfile.php', I get a simple message displayed that simply says, 'No Input Specified'. This could be any mistyped link, or broken link. PHP is trying to interpret the command, since you have specifically sent that file to your PHP processor, but there is no input to process.
#----------------------------------------#
RewriteCond %{REQUEST_FILENAME} ^(.*)\.(php|htm|css|js)$ [NC]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteRule ^(.*)\.(php|htm|css|js)$ - [F,L]
#----------------------------------------#
- Yes, I process my CSS and HTM and JS as PHP. This allows my files to be G-Zipped, before they are sent. That saves me 80 percent in bandwidth fees, and also allows me to pop in some random PHP if desired, without having to process special settings for PHP-JS or PHP-CSS or PHP-HTM, AKA: pjs, pcss, phtm.
- If the file is one of these, but does not exist, then no further processing happens, it sends a forbidden page. This is due to any later code, that might process a link, and turn it into a real link. There are a few exploits related to twisted rewrite rules, sending an invalid link, that looks safe, but the rewrite rules in place, turn it into a link that exposes or crashes your server or files.
- The other reason this is handy. If someone copies a 'Poor constructed link', one that requires constant processing with every call, you will be forever doomed to rewrite on every call from that link. It is better to load a dead page, so they research how to steal your link properly. Which leads to the last line I offer. Hotlink protection that works. Even on virtual servers.
#----------------------------------------#
RewriteCond %{REQUEST_FILENAME} ^(.*)\.(jpg|gif|png)$ [NC]
RewriteCond %{REQUEST_FILENAME} !^(.*)blank\.gif$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?myvirtualsite\.(mysite\.)?com(/)?(.*)$ [NC]
RewriteRule ^(.*)\.(jpg|gif|png)$ http://www.myvirtualsite.com/blank.gif [R,NC,L]
#----------------------------------------#
- Wow, that's a mouth-full... The first line checks to see if the file is (jpg |or| gif |or| png). Next, we ensure that the replacement image does not trigger an endless loop. The replacement image is a gif, but it is named blank.gif. The second line stops processing unless the image is NOT '...blank.gif'. Next, we ensure the images that should be blocked, are NOT blocked by our servers. In this case, the 'myvirtualsite' is hosted on a baseURL site 'mysite.com'. The URL is realy 'www.myvirtualsite.com' or 'myvirtualsite.com', but internal files may write the virtual name, not just the public name.
- This line of code says (www.) is optional, and (mysite.) is optional. This handles all four possible variations. There is one more line you can add, which allows 'BLANK' referrers. ^$ will allow a blank referrer. I do not suggest that, as 95 percent of legitimate browsers do not tamper with REFERER. Only hackers, and people who are tricked into thinking they are actually browsing with an anonymous browser, robots, and spiders have removed referrer. There are rare instances where an ISP or HOST has removed or faked the referrer. Personally, I do not want to place that 95 percent at risk, from that 5 percent of undesired exposure.
- Lastly, the actual Rewrite, will replace any image which is (jpg,gif,png) but not blank.gif and not if the referrer is your own website. (You will be able to load all your images in your pages, only hotlink thieves will not.)
- There is a proper place for ^$ to be set, that would be in a folder where you DO want to allow files to be hotlinked. I have a temp-folder, used for my own personal use of forum images, which are all hotlinked. I simply use limits, and change the image into URL IMAGE with the site-name, once that limit is reached. If they want to view it, they will come. I don't like to waste bandwidth on drive-by visits.
RESOURCES:
(perishablepress.com) Stupid-htaccess-tricks.
(www.askapache.com) Apache-htaccess.
|
