Joomla Security Guide

There is no such thing as 100% secure CMS. To minimize possibility of your website compromise and to keep your Joomla website secure from hackers we recommend taking these steps. Feel free to edit this Wiki and suggest your own protection countermeasures and enhancements. This Wiki is open for modification.

8 MOST effective tips to optimize your Joomla website security

Use the latest Joomla security update

Be on the lookout for latest exploits

You can check for available Joomla exploits @ Joomla Exploits Aggregator

Use secure username and password for administrators

Don't tell everyone about your configuration

Change the default database prefix (jos_)

Most SQL injections that are written to hack a Joomla! website, try to retrieve data from the jos_users table. This way, they can retrieve the username and password from the super administrator of the website. Changing the default prefix into something random, will prevent (most / all) SQL injections.

You can set the database prefix when installing your Joomla! website. If you've already installed Joomla! and want to change your prefix, do the following:

  1. Log on to your Joomla! back-end.
  2. Go to your global configuration and search for the database
  3. Change your database prefix (Example: fdasqw_) and press Save.
  4. Go to phpMyAdmin to access your database.
  5. Go to export, leave all default values and press Start. Exporting the database can take a while.
  6. When done, select all code and copy it to notepad (or any other text editor)
  7. In phpMyAdmin, select all tables and delete them
  8. In notepad, do a Search & replace (Ctrl + H). Set the searchterm to jos_ and change it 
     into your new prefix 
    (Example: fdasqw_). Press "Replace all".
  9. Select everything in your notepad file and copy it. In phpMyAdmin, go to SQL, paste the 
     queries and press Start.

Remove version number / name of extensions

Most vulnerabilities only occur in a specific release of a specific extension. Showing MyExtension version 2.14 is a really bad thing. You can modify this message to only the name of the extension by doing the following:

  1. Retrieve all files of the extension from your server.
  2. Open up Dreamweaver.
  3. Load any file from the extension that you just downloaded to your local machine.
  4. Use the Search function and set the search to Search through specified folder. Navigate to the
     folder where you
     downloaded the exploit to.
  5. Set the search term to "MyExtension version 2.14" and press OK.
  6. When found the correct file, remove the version number.
  7. Upload the changed file to your server and check if the changes are made.

Use a SEF component

Most hackers use the Google inurl: command to search for a vulnerable exploit. Use Artio, SH404SEF or another SEF component to re-write your URL's and prevent hackers from finding the exploits.

Additionally, you'll get a higher rank in Google when using search engine friendly URL's. Keep Joomla! and extensions up to date

This one is pretty obvious. Always check for the latest versions of Joomla! and the extensions you're using. Many vulnerabilities are resolved most of the times in later versions.

Use the correct CHMOD for each folder and file

Setting files or folders to a CHMOD of 777 or 707 is only necessary when a script needs to write to that file or directory. All other files should have the following configuration:

   * PHP files: 644
   * Config files: 666
   * Other folders: 755

Delete leftover files

When you installed an extension that you didn't like, don't set the extension to unpublished. If you do, the vulnerable files will still be on your website. So simply use the un-install function to totally get rid of the extension.

For additional countermeasures that will enhance your website security follow these steps.

Choose a Qualified Hosting Provider

The most important decision

• Probably no decision is more critical to site security than the choice of hosts and servers. However, due to the wide variety of hosting options and configurations, it's not possible to provide a complete list for all situations. Check this unbiased list of recommended hosts who fully meet the security requirements of a typical Joomla site. (FAQ)

Shared server risks

• If you are on a tight budget and your site does not process highly confidential data, you can probably get by with a shared server, but you must understand the unavoidable risks. Most of the tips listed below are appropriate for securing sites on shared server environments.

Avoid sloppy server configurations

• For a real eye-opener, read this report on thousands of sites that allowed Google to index the results of phpinfo(). Don't make this mistake on your site! The report includes alarming statistics on the percentage of site that use depreciated settings such as register_globals ON or that don't have open_basedir set at all: By the way, if phpini and register_globals are unfamiliar terms you are probably not ready to securely manage your own site.

Configuring Apache

Use Apache .htaccess

See also .htaccess examples

• Block typical exploit attempts with local Apache .htaccess files. This option is not enabled on all servers. Check with your host if you run into problems. Using .htaccess, you can password protect sensitive directories, such as administrator, restrict access to sensitive directories by IP Address, and depending on your server's configuration, you may be able to increase security by switching from PHP4 to PHP5.

Joomla ships with a preconfigured .htaccess file but *you* need to choose to use it. The file is called htaccess.txt to use it rename it to .htaccess and place it in the root of your webpage.

• Consider following the "Least Privilege" principle for running PHP using tools such as PHPsuExec, php_suexec or suPHP. (Note: These are advanced methods that require agreement and coordination with your hosting provider. Such options are enabled or disabled on a server-wide bases, and are not individually adjustable on shared servers.)

Use Apache mod_security

• Configure Apache mod_security and mod_rewrite filters to block PHP attacks. See Google search for mod_security and Google search for mod_rewrite. (Note: These are advanced methods that usually require agreement and coordination with your hosting provider. Such options are enabled or disabled on a server-wide bases, and are not individually adjustable on shared servers.)

Configuring MySQL

Secure the database

• Be sure MySQL accounts are set with limited access. The initial install of MySQL is insecure and careful configuration is required. (See the MySQL Manuals) Note: This item applies only to those administering their own servers, such as dedicated servers. Users of shared servers are dependent on their hosting provider to set proper database security.)

Configuring PHP

Understand how PHP works

• Understand how to work with the php.ini file, and how PHP configurations are controlled. Study the Official List of php.ini Directives at http://www.php.net, and the well-documented default php.ini file included with every PHP install. Here is the latest default php.ini file on the official PHP site.

Use PHP5

• Currently, both PHP4 and PHP5 are maintained, and both are often available on servers. Before PHP4 becomes obsolete, upgrade your custom scripts to PHP5. Don't worry about core Joomla code; all current versions are PHP5 compatible. (See PHP News)

Use local php.ini files

• On shared servers you can't edit the main php.ini file, but you may be able to add custom, local php.ini files. If so, you'll need to copy the php.ini files to every sub-directory that requires custom settings. Luckily a set of scripts at B & T Scripts and Tips can do the hard work for you.

There are a few important things to keep in mind.

1. Local php.ini files only have an effect if your server is configured to use them. This includes a php.ini file in your http_root directory. You can test whether or not these file affect your site by setting an obvious directive in the local php.ini file to see if it affects your site. 2. Local php.ini files only effect .php files that are located within the same directory (or included() or required() from those files). This means that there are normally only two Joomla! directories in which you would want to place a php.ini file. They are your http_root(your actual directory name may vary), which is where Joomla's Front-end index.php file is located, and the Joomla! administrator directory, which is where the Back-end administrator index.php file is located. Other directories that don't have files called via the Web do not need local php.ini files. 3. If you have a php.ini file in every directory, some script probably did this for you. If you didn't intend it to happen, you probably should root them out, but given #2 above, you probably only have to panic about the php.ini files in http_root and the administrator directories.

Use PHP disable_functions

• Use disable_functions to disable dangerous PHP functions that are not needed by your site. Here is a typical setup for a Joomla! site:

    disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open

Use PHP open_basedir

• open_basedir should be enabled and correctly configured. This directive limits the files that can be opened by PHP to the specified directory-tree. This directive is NOT affected by whether Safe Mode is ON or OFF.

The restriction specified with open_basedir is a prefix, not a directory name. This means that open_basedir = /dir/incl allows access to /dir/include and /dir/incls if they exist. To restrict access to only the specified directory, end with a slash. For more information, see PHP Security and Safe Mode Configuration Directives.

   open_basedir = /home/users/you/public_html

In some system configurations, at least with PHP 4.4.8, the use of the trailing slash to restrict the access to only the specified directory may cause Joomla to warn JFolder::create: Infinite loop detected when saving the Back-End Global Configuration. This warning is triggered because PHP file_exists() function fails, for example, when asked if /home/user/public_html/joomla_demo exists and open_basedir is set to /home/user/public_html/joomla_demo/ (see the trailing slash).

Additionally, if open_basedir is set it may be necessary to set PHP upload_tmp_dir configuration directive to a path that falls within the scope of open_basedir or, alternatively, add the upload_tmp_dir path to open_basedir using the appropriate path separator for the host system.

   open_basedir = /home/users/you/public_html:/tmp

PHP will use the system's temporary directory when upload_tmp_dir is not set or when it is set but the directory does not exist, therefore it may be necessary to add it to open_basedir as above to avoid uploading errors within Joomla.

Adjust magic_quotes_gpc

• Adjust the magic_quotes_gpc directive as needed for your site. The recommended setting for Joomla! 1.0.x is ON to protect against poorly-written third-party extensions. The safest method is to turn magic_quotes_gpc off and avoid all poorly-written extensions, period.

   Joomla! 1.5 ignores this setting and works fine either way. For more information, 
   see PHP Manual, Chapter 31. Magic Quotes.

    magic_quotes_gpc = 1

Don't use PHP safe_mode

• Avoid the use of PHP safe_mode. This is a valid but incomplete solution to a deeper problem and provides a false sense of security. See the official PHP site for an explanation of this issue.

    safe_mode = 0

Don't use PHP register_globals

• Automatically registering global variables was probably one of the dumbest decisions the developers of PHP made. This directive determines whether or not to register the EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables where they become immediately available to all PHP scripts, and where they can easily overwrite your own variable if you're not careful. Luckily, the PHP developers long since realized the mistake and have depreciated this 'feature'.

If your site is on a shared server with a hosting provider that insists register_globals must be on, you should be very worried. Although you can often turn register_globals off for your own site with a local php.ini file, this adds little security as other sites on the same server remain vulnerable to attacks which can then launch attacks against your site from within the server. For more information, see ZEND Chapter 29. Using Register Globals.

    register_globals = 0

Don't use PHP allow_url_fopen

• Don't use PHP allow_url_fopen. This option enables the URL-aware fopen wrappers that enable accessing URL object like files. Default wrappers are provided for the access of remote files using the ftp or http protocol, some extensions like zlib may register additional wrappers. Note: This can only be set in php.ini due to security reasons.

    allow_url_fopen = 0

Setup a backup and recovery process

The most important rule:'

Thou shalt at all time be able to return your site to a previous working state through regular use of a strong, off-site backup and recovery process. Be sure your backup and recovery process is in place and tested BEFORE you go live. This is the single best way (and often the only way) to recover from such inevitable catastrophes as:

  1. A compromised/cracked site.
  2. Broken site due to a faulty upgrade.
  3. Hardware failure, such as dead hard drives, power failures, server theft, etc.
  4. Authoritarian government intervention. (More common than some think.)
  5. Needing to quickly relocate to a new server or hosting provider.

Site Administration

• Use well-formed passwords
• Change passwords regularly and keep them unique. Use a random combination of letters, numbers, or symbols and avoid using single names or words found in a dictionary. Never use the names of your relatives, pets, etc. Search the forums for a script supplied by Wizzie that automatically changes passwords. This is a great tool for administrators or multiple sites.

Follow a password leveling scheme

• Most users may not need more than three levels of passwords and webmasters no more than five. Each level must be completely unrelated to the others in terms of which usernames and passwords are used.

Maintain a strong site backup process

• Never rely on others' backups. Take responsibility for your backup procedures. Many ISPs state in their contract that you can not rely solely on their backups.

• Monitor crack attempts

• VPS and dedicated server users can run TripWire or SAMHAIN. These applications provide exhaustive file checking and reporting functionality, and can be installed in a stealthy manner to help protect themselves in the event of a serious infiltration. (Note: Users of shared servers can not use this technique.)

Perform automated intrusion detection

• Use an Intrusion Prevention/Detection Systems to block/alert on malicious HTTP requests.

• Perform manual intrusion detection

• Regularly check raw logs for suspicious activity. Don't rely on summaries and graphs.

• Stay current with security patches and upgrades

• Apply vendor-released security patches ASAP.

• Proactively seek site vulnerabilities

• Perform frequent web scanning.

• Proactively seek SQL injections vulnerabilities

• Use tools such as Paros Proxy for conducting automated SQL Injection tests against your PHP applications.

   * Google Search
   * Wikipedia Article

• Use shell scripts to automate security tasks

• Search the forums for these popular scripts:

   * Joomla! Version Checking
   * Joomla! Component/Module Version Checking
   * Exploit Checking

Secure Testing and Development

Develop locally, deploy globally

• Develop and test your site on a local machine first. Installing Joomla locally is not as hard as it may sound, and the exercise will greatly boost your confidence.

Use an IDE

• Consider using an Integrated Development Environment (IDE). One free IDE that many Joomla! developers use is Eclipse. See Setting up your workstation for Eclipse development for instructions on installing Eclipse.

Use a versioning system

• Be able to roll back to an earlier version of your site using a modern version control system, such as CVS, Subversion, or git. The Eclipse IDE indicated above includes a Subversion plugin. This allows you to work with the Joomla! source repository as well as other projects hosted on JoomlaCode.

More suggested tools

• Check out the Joomla! community's list of popular Developer Software and Tools.

Setup a backup process first

The most important rule

   Thou shalt at all time be able to return your site to a previous working state through regular
   use of a strong, off-site backup and recovery process.

   Be sure your backup and recovery process is ready and tested BEFORE your site goes live. This 
   is the single best way (and often the only way) to recover from such inevitable catastrophes
   as:

  1. A compromised/cracked site.
  2. Broken site due to a faulty upgrade.
  3. Hardware failure, such as dead hard drives, power failures, server theft, etc.
  4. Authoritarian government intervention. (More common than some think.)
  5. Needing to quickly relocate to a new server or hosting provider.