When looking at Joomla from a security standpoint, it is interesting to note that when included in a comparison of the top 3 CMS platforms - Joomla is the shining star! Before diving into the things that can make Joomla more secure, let's have a look at the market share of the top 3 platforms and the security vulnerabilities of those same 3 platforms for the past 6 years.

It's interesting to view these statistics and learn that the most popular CMS is the least secure. While making their platform more user friendly, they have also made it less secure. This target rich environment has become an infested swamp of hacked sites.


CMS Market Share

  • Wordpress: 58%
  • Joomla: 7%
  • Drupal: 4%

CMS Market Share from W3Techs

CVE Reported Vulnerabilities in 6 years

  • Wordpress: 136
  • Drupal: 103
  • Joomla: 88

CVE Vulnerabilities site


Looking at these numbers, it's clear that Wordpress is much less secure than both Joomla and Drupal. The reason for Wordpress popularity is 2 part - the platform is dead simple for site administrators and it is (optionally) a hosted platform, allowing people to have a website hosted by Wordpress in just a few minutes. In terms of features and flexibility, Joomla and Drupal both beat Wordpress hands down. In terms of security - Joomla beats both Drupal and Wordpress.

A personal anecdote: A few years ago, I was approached to build a website and a mobile app by a client. The app was much more important, so I completed that task first. When it came time to build the website, I was informed that an investor demanded that a particular developer build the site. I was disappointed, but there was little I could do. The new site was built on Wordpress and within a few months the site was hacked and sent out thousands of spam and virus emails. This hack caused their domain to be added to several spam RBLs (Realtime Black List) and severely impacted their business.

As I was not involved with the website, I have no information on how the site was hacked. I can only offer advise to those seeking a website and that's what this article is. The first piece of advise I'll offer - if you're going to hire someone, make sure they know what they're doing. Your website is an extension of your business and deserves as much attention to detail as the rest of your business.

Before Installation

Start by listing the items you can and will secure. Don't skip anything, or leave anything out because you don't know how to secure it. The moment you decide to leave a window open because you don't know how to close it - is the moment someone breaks in and robs you blind.

Begin by examining the server itself.

  1. Physical Security
    • For many, this aspect will be a moot point. Many use hosting companies and only employees of the hosting company will ever have physical access to the server. For those who are hosting on their own hardware, take care that your server is secure. There are people who specialize in social hacks and only need a few unattended minutes with physical access to a server to compromise it. Take inventory of your physical security, and if it isn't rock-solid - upgrade!
  2. Operating System Maintenance
    • Again, this will not be an option for many who use hosting companies and are living with the software provided on their hosted server. For those who maintain their own servers, it is important to stay on top of operating system and webserver related updates. Many updates fix bugs and vulnerabilities. Unless you're the very rare target of a zero-day exploit, keeping your server updated will mitigate the risk of exploit through vulnerability.
  3. Running Services
    • Is your server running a Telnet service? What about fingerd? Did you set up an IRC server for your buddies? These are important questions, and it's important to realize that any unnecessary service can be a point of access to an attacker. If you aren't using a service for your site - secure it or remove it.
  4. Encryption
    • With services like Letsencrypt.com, there is absolutely no reason not to run an SSL encrypted site. With encryption, you can protect your users credentials at the same time as you're protecting your administration credentials. As a bonus, your SERP will benefit and your customers/visitors will feel more secure with your site. There is no downside to encrypting - get to it!
    • You aren't done until you score A+ on SSLLabs
  5. Methods of Connection
    • Once you start using encrypted connections, don't do anything unencrypted. Don't use Telnet, use SSH. Don't use FTP, use SFTP. If you use a C-Panel via your host - be sure it's on an encrypted connection. It's important that you consider any unencrypted connection as a security risk. Being paranoid is not a bad thing when it comes to server security.
    • Also consider blocking avenues to mask an attackers identity such as the TOR network. It's a common misconception that attacks via TOR cannot be tracked, however, the TOR network itself publishes a list of exit nodes. Unless you have a good reason to allow traffic visiting through a TOR exit node - you can block one method attackers use to mask their identity.

The rest of the items are a little more Joomla specific and will be addressed more in-depth.

Filesystem Permissions

Filesystem permissions can be a tricky subject. Many webmasters aren't familiar with Unix filesystem permissions, so they accept whatever permissions happen by default when they unzip the installation package. I've been running Linux for 20 years (exclusively for 15 years), so this is something I'm intimately familiar with. Mac power users will have some familiarity with this, but seldom are Windows users accustomed to these types of settings.

This lack of knowledge can be the cause of many issues - the most extreme being that your site becomes vulnerable to edit and overwrite by an unintended third party. It cannot be stressed enough, the importance of filesystem permissions.

There is no cookie-cutter answer that can be given to explain what permissions your server needs. I can't even tell you what the username of the webserver is (although, for the purpose of this section we will assume it is www-data) or what your website root directory is (again, for the purpose of this section we will assume it is /var/www/html).

Please, do a sanity check on the values of these commands to determine if they are correct for your server.

cd /var/www/html
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chown -R www-data .

Again, please verify that these settings are appropriate for your server. The wrong path may cause all of the commands to fail (or may cause you to change something you shouldn't), and the wrong server username may also prevent the server from being able to see your contents. Other servers may require the server group to have write capabilities - which would change the numbers above to 664 and 775 respectively.

Learning about filesystem permissions has a steep learning curve for those not familiar with them already. The following links may be helpful when learning about permissions.

You have some learning to do, but it is well worth it when your server security is at stake.

PHP has an additional configuration which can be used to prevent rogue scripts from going beyond the boundaries of your Joomla installation. The PHP open_basdir configuration sets restrictions on where PHP is allowed to go within your filesystem. Obviously, special configurations should be reflected in this setting, but a good default is for your .htaccess file is below. This allows PHP to open the Joomla install path and anything inside of it, as well as access /tmp.

php_admin_value open_basedir "/path/to/joomla:/tmp"

One last thing - do not, under any circumstances EVER give permissions of 777!! If someone suggests that you do this, they either do not know what they're talking about, or they want your server to be vulnerable. Either way, the 777 permission is dangerous. Don't do it!

If anyone tells you to type 777, stop listening to them!

Initial Configuration

Initial configuration plays a key part in your overall site security. The most obvious consideration is the passwords you choose for your site, but they shouldn't be the only thing you focus on when beginning the installation.

Database Security

Host name privilege

When creating a database, the database administrator has the option to restrict access to the database to certain hosts (local or remote systems). The lazy option would be to use the wildcard % (any host), but this creates a vulnerability. If open to any host request, an attacker might begin a bruteforce attack against the database server.

The safest option when creating database permissions is to specify the host by IP address (or localhost if appropriate). If the future requires you to grant access from another host, it's a quick configuration and much less painful than recovering a hacked database.

Usernames and Passwords

Be creative! Reusing the same username/password combination you use on the server is dangerous! Remember, the database username and password are stored in plain text (unencrypted) in the configuration.php file. If someone is able to exploit your site and retrieve that information, they could gain access to your site via other (more direct) means. Very dangerous! Pick a unique username and password to access your database.

Joomla Evolution

I started using Joomla back it was called Mambo (if that offends you, just let it go). Back then, the database tables were always prefixed "mos_". When the Joomla fork occurred the table prefix became "jos_". Many were unhappy about that, and they hacked their core files to accomplish a prefix change.

Fast forward 2 major revisions and today we enjoy an installation script that generates a random table prefix.

For those who don't see the significance of a random table prefix - imagine if a burglar knew half of the pattern for your house key. A random prefix makes certain SQL attack vectors useless because the table names are not known. If you can't see the target, you have no hope of hitting it.

Sample Data

Do not install sample data unless you have a good reason. Choose "None". Picking any of the other options enables modules that you would be disabling later.

Administrator Credentials

Change the admin username to something else. Under no circumstances should you leave the username as "admin".

A piece of advise about passwords:

Length and content are key. Longer is better and if you're going to use words - misspell them. An 8 character password can be cracked in a few seconds. A 10 character password takes days to crack. I don't use passwords with fewer than 12 characters, and my passwords do not contain any actual words.

Post-Installation

What you do immediately after installation is very important. Fortunately, upon completing installation, Joomla offers to perform the very first necessary task you should do. When offered, delete the "Installation" folder! This folder may provide an attacker the ability to completely reconfigure your site. Because that is part of the installation process, it's listed in this introduction and separate of the items below.

Rename htaccess.txt to .htaccess

Many security configurations can be made in the .htaccess file. Some of these security configurations will be covered later in this article.

Optional
Although optional, this is highly recommended.
Benefits
The list is long, but here are a few benefits of renaming the htaccess file:
  • Enables the next step in this list, hiding URL variables from attackers by using URL rewriting, making their task of infiltration more difficult.
  • Additional protection from a few known attack vectors are built into the default htaccess file.
  • With additional configurations (below), discourages fingerprinting (identifying that your site runs Joomla)
Procedure
Browse to your Joomla root directory and locate the file named htaccess.txt. rename that file to .htaccess using whatever method you have available. In an SSH session, it is as simple as typing mv htaccess.txt .htaccess.
Considerations
Please pay close attention to these possible pitfalls:
  • If you choose to copy htaccess.txt to .htaccess - be sure to move or rename this backup copy of htaccess.txt. One of the fingerprinting techniques used is to look for the htaccess.txt file and compare it to known versions of that file in order to determine that the site is running Joomla, and determine which version of Joomla is running.
  • The htaccess.txt file may reappear when you receive a Joomla update (if there was an update to the file). So each time you update Joomla - look for a new htaccess.txt file. It may benefit you to learn what changes were made and replace your .htaccess file with this new version - or incorporate the changes to your modified .htaccess file.

Enable "Search Engine Friendly URLs" and "Use URL Rewriting"

Using SEF URLs in your site not only helps with the search engine visibility, it also hides information present in non-SEF URLs which may help attackers to craft attacks that are tailored to your configuration or installed components.

Optional
Although optional, this is highly recommended. This depends on your decision above. If you did not rename htaccess.txt to .htaccess - do not enable "Use URL Rewriting".
Benefits
Enabling this feature benefits you in two ways:
  1. Decreases the ability for fingerprinting by removing URL variables which can assist an attacker from identifying that your site runs Joomla.
  2. Boosts your search engine visibility by replacing URL variables that the search engines ignore with words that are (potentially) related to your content.
Procedure
Follow these steps:
  1. In the Joomla /administrator backend, click the "System" menu and choose "Global Configuration".
  2. Click the "Site" tab if it is not already active.
  3. In the right column (at the top), locate the "Search Engine Friendly URLs" option and set it to "Yes"
  4. In the right column (at the top), locate the "Use URL Rewriting" option and set it to "Yes"
Considerations
To fully benefit from SEF URLs, take the time to learn about how search engines treat keywords in the URL.

Turn off "Show Joomla Version"

This default setting is absolutely unnecessary, and should never be left on. A website that identifies its software and version is an attackers dream.

Necessary
Although this is not an attack vector or specific vulnerability, it discloses important information that should not be revealed. Do not overlook this setting!
Benefits
Information disclosure is reduced in one case, and removed in another:
  1. The joomla version number is removed from meta generator tag.
  2. When GZip compression is also enabled, the "X-Content-Encoded-By: Joomla!" HTTP header is not sent.
    • This was once very difficult to remove, and required the administrator to either hack the Joomla core files (not recommended), or use the RicheyWeb "Clean Response" plugin.
Procedure
Follow these steps:
  1. In the Joomla /administrator backend, click the "System" menu and choose "Global Configuration".
  2. Click the "Site" tab if it is not already active.
  3. In the left column (at the bottom), locate the "Show Joomla Version" option and set it to "No"
Considerations
This is just one of several steps necessary to fully remove this disclosure. Others will be detailed later in the "Fingerprinting Countermeasures" section.

Disable Unnecessary Extensions

Joomla ships with many components, modules and plugins that you may not need. Most are enabled by default. For example, I rarely use the Banners component, yet it is enabled by default. Likewise, if you don't plan on using the Joomla Contacts component, there is no reason for it to be enabled.

Do some research into the extensions Joomla ships with, and make a list of the features you plan to use. If it isn't something you need - disable it.

Necessary
Fewer active extensions means fewer attack vectors.
Benefits
Here are a few:
  • Reduces the number of attack vectors to your site.
  • Reduces clutter in the /administrator component menu, module, and plugin management screens.
  • Makes you more familiar with what's on your site, which can't be a bad thing.
Procedure
Follow these steps:
  1. In the Joomla /administrator backend, click the "Extensions" menu, hover over "Manage" and click "Manage" in the submenu.
  2. Browse, search, or filter your way to the extensions you wish to disable.
  3. Clicking the green checkmark or selecting the checkbox and clicking the "Disable" menu option will disable the extension.
Considerations
This can be a dangerous process for those not familiar with the necessary extensions.
  • If you don't know what it is or does, don't disable it.
  • Disabling the wrong thing can make your site unusable.
  • If an extension appears with a lock instead of a green checkmark - it cannot be disabled.

Hide /administrator

This isn't as hard as it sounds, but although you have options, some are just as bad as leaving it visible.

There are several popular methods, one of which is a RicheyWeb extension called AdminExile and another is a very new RicheyWeb extension called Clipper. Without naming extensions or developers, I'll describe the methods and associated pitfalls.

.htaccess/.htpasswd/HTTP Authentication

This method, while secure, fails to address the fingerprinting aspect of securing the site. Upon arrival, an authentication popup appears - indicating that something exists at /administrator. Additionally, HTTP authentication is vulnerable to brute force attack - as it isn't CSRF token secured like Joomla forms (generally) are. An attacker can hammer away knowing that the only way he's getting caught is if an administrator sees it in the log files.

URL Tokens

This is a method used by Clipper and AdminExile as well as several other security extensions. One key difference is that Clipper and AdminExile prevent the Joomla session cookie from being sent. Other URL token extensions block access to /administrator - but allow the session cookie to be sent. If the cookie is received by an attacker, he immediately knows that something exists at that URL and can continue to probe for a means of entry.

IP Whitelist

This is a method used by Clipper and AdminExile and others. Again, this method is secure if the session cookie is blocked. As with URL tokens, AdminExile and Clipper block the session cookie where others do not.

Necessary
You can't hack a form that is inaccessible.
Benefits
The list is long, here are two:
  • Prevent fingerprinting
  • Stop brute force attacks
Procedure
Choose your method and follow the instructions included with it. There are so many options, it is not practical to list them all.
Considerations
Whatever method you choose, determine how to circumvent it. My number 1 support request for AdminExile is how to recover from forgotten keys.

Choose Extensions Wisely

With over 7000 extensions in the Joomla Extension Directory, it can be tempting to install a ton of extensions because you might want to use them. That is a very common mistake. Not all developers are created equal. Some are more security conscious than others, and that's something you can learn with research.

If you absolutely MUST install an extension to check it out - don't do it on a live server. I don't know any developers who don't have at least one development server. Spend a few minutes to install a local lamp server that you can sacrifice to potentially bad extensions. The last thing you want to do is try to recover your site from a backup - trust me on that.

Who is the Author?

The first thing you want to do when looking at an extension is to take a look at the author, their website, their other extensions and most importantly - the reviews on this and their other extensions. As a developer with many extensions in the JED, I can tell you that bad reviews stick. The JED moderators are not accommodating when it comes to reviews. In the years I've spent developing Joomla extensions and receiving JED reviews - only one was ever removed, and that was a review made by the author of a competing extension who attempted to get a better rank by breaking the rules and giving me a bad review. For his efforts - all of his extensions were removed from the JED and he is the proud recipient of a lifetime ban.

The VEL is Your Friend

https://vel.joomla.org/

Joomla publishes a "Vulnerable Extensions List", where any extension reported to have a vulnerability can be found. During its time on the VEL - an extension is removed from the JED until the author fixes the issue. Before installing an extension, search for the authors name and their other extensions on the VEL. Chances are good that the author of one vulnerable extension is the author of multiple vulnerable extensions.

Reviews on the Web

The JED isn't the only place to find reviews. Some people don't have accounts on the JED, they just download extensions. Reviews, both good and bad, exist on personal blogs - Twitter feeds and even Facebook.

An Exact Science

Unfortunately, there isn't any real way to know unless you read the code. I suspect that if you're reading this article, you are either a developer critiquing it, or you're reading it to learn. Developers, please give me some feedback on things I may have missed or explained badly. If you're here to learn, I hope this helps.

Updates and Backups

Stay Up-to-Date

It is more likely that a software update is issued to fix a bug or security flaw than it is a new version or feature. It is important to check often, because a security vulnerability report spreads like wildfire through the internet hacking and cyber crime communities. When it becomes possible to exploit a large number of websites, hackers take notice. Even though Joomla doesn't have the largest market share - it's number 2 and that is an appealing target.

Joomla is the product of a very active community. Vulnerabilities don't go unnoticed for very long and as a result, Joomla receives frequent updates. Because of these frequent updates, Joomla has evolved to contain a built-in upgrade notification for both the CMS and extensions. When properly configured, your site can notify you when updates are available.

Something you should plan to do on a regular basis is check for both Joomla and extension updates. Set it as a calendar item, or program your phone to remind you at regular intervals.

Yes, it's that important!

Backups are your Lifeline

Murphy's Law: Anything that can go wrong, will.

Richey's Law: Anything worth backing up, is worth backing up twice.

No Cookie Cutter Solutions

Whatever backup method you choose, don't just assume that it works. Be sure you know how it works and that it works. Make a backup, take that backup to another server, and restore it. Understand the process so that if you need to restore from a backup, you aren't spending your time reading a manual or trying to figure out what comes next.

Do you need it? Yes you do!

My standard backup for my websites consists of everything on that server, for that website.

  1. Nightly backups of:
    • The site file system
    • The database
    • The server config for the site
    • The SSL certificates
    • The site access and error logs

Do you really need the log files? My log files rotate every seven days. With my backup rotation strategy, I have 14 days of logs I can review in case of a security breach. I don't know if I'll need them until I do, so I keep a copy and that is my suggestion.

How long to keep them

This depends on your application. I have a customer that requires 1 year of logs. My standard, however, is seven days for all server files. Additionally, I keep six months of monthly backups. The last backup of every month is kept for six months. Maybe it's overkill, but I'd rather err on the side of caution. Besides, storage space is cheap.

Fingerprinting Countermeasures

Protect the /administrator URL

Although listed above, this change is important enough to mention again.

One telltale signature of Joomla is the presence of an /administrator URL. Simply visiting a domain and adding /administrator could disclose that the site is running Joomla. Early versions even gave the Joomla version on the /administrator login page. Since those early days, much has been learned by the Joomla core developers and many 3rd party developers.

Years ago, an attempt to make the /administrator URL a dynamic configuration failed due to technical reasons. It was possible, and many did it successfully, but it required constant maintenance and was frequently broken after Joomla updates.

Today, many extensions exist to protect the /administrator area - but which is the "best" solution to secure /administrator, but to also prevent detection.

  1. AdminExile system plugin
  2. Clipper system plugin, with the Admin Protect plugin installed and enabled

Remove the Joomla generator meta tag

The generator tag is a fingerprinting item used by attackers to determine that your site runs Joomla. If configured, your site may also disclose the Joomla version inside of the generator tag content. Many options exist to remove this meta tag.

  1. ByeByeGenerator system plugin
  2. Clipper system plugin, with the Remove Generator plugin installed and enabled
  3. Several others exist, but few are as efficient as the two RicheyWeb options above.

Clean references to com_ajax and other component options

When your site is running with URL Rewrite enabled, most of the links within Joomla are converted to SEF URLs. Some, however, are not. On every page that contains a mod_login, a keepalive javascript will reference (directly) the com_ajax extension with a fingerprintable URL. Any extension that calls upon com_ajax to perform keepalive will do this. Many other extensions make this fingerprinting possible. It is easy to overcome with some simple replacements.

  • Using something like Re-Replacer from Regular Labs - create a new entry that searches the output for "index.php?option=com_ajax&" - replacing it with "component/ajax?"
  • Look in your output for any URL containing "index.php?option=", and use a similar replacement technique to prevent disclosing that your site runs Joomla.

Hiding SQL, XML and INI files

There is seldom a need to directly serve SQL, XML or INI files directly. Usually Joomla output is the favicon, template output, javascript, and CSS (and maybe some webfonts). But every Joomla extension has at least one XML and at least a couple of INI files. Fingerprinting Joomla becomes trivial when you can type a URL to find the EXACT version of Joomla running on a site. Try it out:

https://www.joomla.org/administrator/manifests/files/joomla.xml

You can't do that on RicheyWeb though...

​https://www.richeyweb.com/administrator/manifests/files/joomla.xml

As part of the Joomla installer, JForm, and JLanguage - these files are absolutely essential to Joomla frontend operation and cannot just be removed. So what can an administrator do?

.htaccess to the rescue!

Using just 3 rules, it's possible to make SQL, XML and INI files completely inaccessible from the web - but still accessible to the Joomla processes that need to use them.

RewriteRule .*\.xml$ - [F,L,NC]
RewriteRule .*\.ini$ - [F,L,NC]
RewriteRule .*\.sql$ - [F,L,NC]

These 3 rules block any attempt to access a file ending with .xml, .ini, or .sql.

If you're running NGINX, you'll have to create a location block

location ~ .*?\.(xml|ini|sql) { 
return 404;
}

Bad Robots

I'm working on a public service to distribute a bad-bots file and instructions to implement in Apache globally, or in .htaccess

It's going to be worth coming back to see this update.

Wrapping it Up

Scan your site!

There are various Joomla security scanners out there (Joomscan is old, but still relevant). Make time to regularly update your site and re-run security tests. The saying goes "An ounce of prevention is worth a pound of cure" - but I believe that is an understatement. When an attacker gains control of your site, you may not know it until it's too late to salvage anything. At that point you must restore from a backup (but which one?)

It's better to be pro-active than to be re-active. Make it safe, keep it safe!

This is a living document and will be modified in the future as new methods are found.