Potentially, yes. Your site can be secure, but you must be careful and vigilant.Long answer
A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user
, and world
permissions on directories and files.
Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html
. This is because it is publicly accessable, world-readable
, and in the case of a CMS-powered site, possibly even world-writable
. That status is the very definition of officially, totally, and utterly insecure
As long as you want the entire world to view your public_html
directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html
contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only
directory becomes a world-accessible, read-write application
If there are ANY vulnerabilities in ANY files in the public_html
directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.
One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html
. Other files should be loaded into applications using such functions as include
. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.The incredible lightness of living outside the fence
To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation
directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.
Granting a world-accessable installer the ability to write to files outside of public_html
would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html
directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.
Currently, most Joomla extensions also have limited support for file locations outside of public_html
. This is a legacy of the Joomla! 1.0.x installation model. Joomla! defense
Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.
See: Advisory: Dealing with hacked websites and hacking attempts.The challenge
The practice of placing everything in public_html
, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny
This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)
During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you can not forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html
makes the issue extremely critical.
The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html
, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html
) they would not be exposed to URL injections.To (Deny, then Allow), or (Allow, then Deny)?
The real problem with the above "all known" qualifier is that it is an allow, then deny
model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.
Consider the logic for a password authentication script. We have essentially two choices:
1) First allow
all access, then deny
any username/password combination that DOES NOT
match the approved list.
2) First deny
all access, then allow
any username/password combination that DOES
match the approved list.
Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.
Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.Blatant appeal to authority
Security is a complex and ever evolving topic, with plenty of room for a wide variety of valid philosophies and models. I personally favor the security model used by Gallery2
.The good news
1) In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outsite of public_html
after you have completed the installation. Whenever possible you should do this.
2) Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation. Below is the relevant code from /includes/defines.php
define( 'JPATH_ROOT' , implode( DS, $parts ) );
define( 'JPATH_SITE' , JPATH_ROOT );
define( 'JPATH_CONFIGURATION', JPATH_ROOT );
define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' );
define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' );
define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );
3) Joomla! 1.5 will be able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.