Support

Admin Tools

#10237 htacess allowing direct access to files in the cache - how much of a security risk

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Admin Tools version
n/a

Latest post by nicholas on Sunday, 22 January 2012 05:39 CST

douglas
Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting Admin Tools User Guide
Have I searched the forum before posting? Yes
Have I read the documentation before posting Yes
Joomla! version: 1.7.3
PHP version: 5.2.17
MySQL version: 5.0.92-community
Host: (optional, but it helps us help you)
Admin Tools version: 2.1.14

Description of my issue:

I have just install the Widgetkit from YOOtheme and in order for it to display correctly I have had to allow direct access to the following files in Server Protection:

cache/widgetkit/widgetkit-185a3c45.css
cache/widgetkit/widgetkit-c7813637.js

Having read your documentation I understand expecting files from the cache to be directly accessed is bad practice for the component, and having just paid 60 EURO for the component I will be contacting them to see if there is a better work around.

My question is how much of a risk is allowing direct access to these individual files represent to my site, and should I simply not use this component?

Many Thanks, Doug

nicholas
Akeeba Staff
Manager
Hi Doug,

You can actually mitigate the risk by allowing only non .php files in that directory. Just add
cache/widgetkit
to "Allow direct access, except .php files, to these directories" textbox in .htaccess Maker and click on Save and Create .htaccess. This will allow only the static media files to be accessible from the cache directory, therefore not compromising your site's security.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

akeebafan
Just curious about:

Having read your documentation I understand expecting files from the cache to be directly accessed is bad practice for the component.


Why would it be bad practice, if the php or js file comes from a trusted component?

nicholas
Akeeba Staff
Manager
It's always bad practice. The cache directory is supposed to be non-web-accessible. That's what a cache does. Moreover, it's one of the directories which are most likely to have wide open (0777) permissions, as components do need them to work. As a result, an attacker could put a malicious PHP file in there. In order to be effective, the attacker needs to run it, by accessing it over the web.

Normally, the .htaccess Maker makes it impossible for an attacker to access such files over the web. In fact, the default settings should only allow the index*.php files in Joomla!'s site root to be web accessible, not any other PHP file. If you allow running PHP files from the cache directory, you jeopardise the security of your system.

Allowing static media files only to be accessed (what I proposed) is much less risky. In fact, the attacker would have to already know the name of a cached CSS/JS file and replace it with something malicious, hoping that an administrator would then load a page making use of the (maliciously modified) file in order to perform an attack, e.g. steal a cookie. Now, that becomes a too elaborate hack and I doubt that this will ever be a common ground attack, like "planting" PHP files is nowadays.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

akeebafan
Thanks for explanation. Not sure whether I agree, though :-)

After installation of Joomla (by default) the cache has the same permissions as every other folder. It shouldn't be necessary to change the permissions to 777 (because THAT would be bad practice :-).


@doug

By the way, Yootheme is probably the only big name in joomla that never had to fix a security vulnerability. Rock solid so to speak :-)

brianteeman
Security vulnerabilities effect everyone http://www.google.co.uk/search?sourceid=chrome&ie=UTF-8&q=yootheme+vulnerability

nicholas
Akeeba Staff
Manager
Actually, tmp, cache, administrator/cache and logs folders are special. They are not web accessible and should at all times be writeable. Your extensions DEPEND on those folders being writable. If they are owned by your account's (FTP) user, your server is not using mod_itk/suPHP and you have not enabled Joomla!'s FTP mode (or enabled it but left the password blank for security reasons) then these directories will be unwritable and your extensions will malfunction. What I described is how 95% of sites running on shared hosts are configured.

Are 0777 permissions really that evil? I've already written all about it. Let me recap this very quickly. 777 is bad because it allows people from other hosting accounts on the same server to write to those directories. OK, so bloody what? I wrote a malicious PHP file to your site's tmp directory, let's say a C99 variant. Now, in order to pwn your site I need to RUN it. Over the web. If you're using Admin Tools Professional's .htaccess Maker OR if you have put the kind of .htaccess I mentioned above in those directories, the potential attacker CAN NOT run the hacking script, ergo can not pwn your site.

You should know me better than that, man. Before I give security advice I have done my homework. And I never suggest people do something that I'd never do on my own sites. In fact, I DO have some sites on shared hosts and I DO have set them up the way I described. The oldest of them was built on early 2006 and has not been hacked, despite other accounts on the same box having been compromised at least four times in the meantime (I know because I'm a friend of the guy owning the server).

What I want to say is that uttering aphorisms like "777 is evil, never use it" is of little use. In fact, if your files are owned by the Apache user and you have 0755/0644 permissions then you are as vulnerable as having 0777 permissions. What we ALWAYS have to do when dealing with security is think. Why is something bad? How can an attacker exploit it? How can we mitigate the risk? If you always do that, you can easily secure a site to make it tough (but: NOT impossible, don't ever think that's possible) to hack.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

akeebafan
@brian

thanks, I realize now that the VEL (the source of my claim) only goes back to 2010 (and that's why I couldn't find anything with CTRL-F :-)!


@nicholas

I only disputed that it is not necessary to set the cache to 777 on a correctly setup server. If you do, then of course other precautions would be necessary. Probably your point is that there are many incorrectly setup server unfortunately ("crap hosts") and that's where your admin tools could be very helpful.

Thanks for clarifying. Learnt quite a few things today :-)

nicholas
Akeeba Staff
Manager
I missed the "correctly setup server" part :) Yes, that's true, if the server is correctly setup you don't need any of this

However, on a properly setup server, each site will have its own user, suPHP/mod_itk or php-fpm will be in use and the home directories will have 0700 permissions, so even with 0777 you would still be perfectly safe. Moreover, the last time I saw a properly setup server it was on a dedicated server. Shared and VPS hosting rarely goes into such great lengths. It takes time to set up something like this and time costs money. I know you get the idea ;)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

douglas
Thank you for your input everybody and your advice Nicholas, I have learnt something today.

All the best, Doug

nicholas
Akeeba Staff
Manager
You're welcome!

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!