Short answerPotentially, yes. Your site can be secure, but you must be careful and vigilant.
Long answerA 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,
group, 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 and
require. 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 fenceTo 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! defenseDespite 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 challengeThe 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 security model.
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 authoritySecurity 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 news1) 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.
Code:
//Defines
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.
