I agree. Something like this should suffice in the root wordfence directory.
Options -Indexes Order Allow,Deny <FilesMatch "^(colorbox|diff|dt_table|fullLog|iptraf|main|phpinfo)\.css$"> Allow from all </FilesMatch> Order Allow,Deny <FilesMatch "^(admin|jquery\.(colorbox-min|(dataTables|tmpl|tools)\.min)|tourTip)\.js$"> Allow from all </FilesMatch> Order Allow,Deny <FilesMatch "^[0-9A-Za-z_-]+\.(jpe?g|gif|png)$"> Allow from all </FilesMatch>
Once you put that there, there will be no need for any other .htaccess files within your plugin. But if you added more CSS and/or JS files or even change their names you’d have to edit this as well. Or just include
Options -Indexesat the top of your current .htaccess file. But what I have above is probably the most secure.
I just remembered, you don’t need to repeat the “Order” directive every time. Only repeat it if you’re going to change the type of “Order” directive.
So this will be a bit faster.
Options -Indexes Order Allow,Deny <FilesMatch "^(colorbox|diff|dt_table|fullLog|iptraf|main|phpinfo)\.css$"> Allow from all </FilesMatch> <FilesMatch "^(admin|jquery\.(colorbox-min|(dataTables|tmpl|tools)\.min)|tourTip)\.js$"> Allow from all </FilesMatch> <FilesMatch "^[0-9A-Za-z_-]+\.(jpe?g|gif|png)$"> Allow from all </FilesMatch>
Thanks. I’m going to just create an index.php file for the directory which should fix this if your server allows dir listings. Let me know if you still think .htaccess is a better idea and why. The reason I prefer index.php is because some servers have selectively disabled the directives you’re using in the htaccess above and cause errors when you include them. e.g. I think “order” is an issue for some configs.
Yeah, it’s up to you. You probably have a better idea of your users’ setups.
But the code I provided is going to be the most secure that you can get, only allowing those static files that need to be accessed at the HTTP level and would definitely provide more protection for future possibilities. It’s pretty much optimized for all versions of Apache. If anyone is on Apache 2.x or higher, I can make it even more optimized and faster.
Those are core .htaccess directives and anyone using Apache or similar, shouldn’t have any issues with them, why someone would disable core directives is beyond me, but it’s possible, so using an index.php file is probably all you can do.
You could offer your users an option. Create the .htaccess file and name it htaccess.txt, and in the readme.txt you can mention for ultimate security they can see if renaming htaccess.txt to .htaccess works without killing the plugin. Really with the order directives I wrote, you don’t need the “Options -Indexes”, I just thought you may want to at least use it or “IndexIgnore *” if you continue to use the .htaccess file you currently have included with the plugin.
I know the rules seem a bit hard to grasp, but they do work. Actually index.html is called before index.php in a lot of setups. So may be it’s possible to get say an index.phtml file in the root of your plugin directory. A blank index.php file will provide no protection. Also a blank index.php will provide no protection if an attacker gets any type of script into your plugin directory, because they would still be able to access it from HTTP.
It’s a hard toss up. You want ultimate security, but at the same time you want ultimate usability among everyone. You’d really have to test to see.
- The topic ‘Directory Listing’ is closed to new replies.