Because Joomla is easy to install and configure, many Web masters are lax when it comes to implementing proper security. Although the Joomla system does everything it can to prevent hacker breaches, it is important for any Web administrator to understand the basics of security and for you to understand the particulars of ensuring that your Joomla system can withstand an attack.
Because Joomla uses four interlocking server technologies (Apache, PHP, MySQL, and Joomla), you must maintain security protection at each link of the chain. For example, poorly handled PHP security can leave Joomla wide open to penetration even if Joomla, MySQL, and Apache are secure. This chapter examines each of the servers and how maximum security can be put into place to minimize the danger from the "Wild Wild West" environment of the Internet.
To minimize security problems you should perform a regular update of all your server software, including Joomla. New security problems are found all the time, and the developers of each software package patch the applications to close loopholes. By keeping your versions updated, you will be less vulnerable to attacks.
Entire books have been written on aspects of hacking attacks, so a complete list is beyond the scope of this book. Nonetheless, there are a number of common attack methods (password, SQL Injection, cross-site scripting, and so on) that are extremely widespread. Any Web master should have at least a passing understanding of how they work.
The following sections provide a brief overview of the ordinary strategies used by hackers to gain access or fault a system. In later sections of this chapter, you'll learn how to configure your Web server, PHP system, and Joomla installation to minimize the likelihood of penetration by these or other methods.
If you want to obtain more detail in this topic area, a great deal of information on Internet security is available through the Unites States Computer Emergency Readiness Team (US-CERT). There are many freely available publications for technical and nontechnical users that are accessible on the US-CERT Web site (www.us-cert.gov).
There are programs that will attempt to breach the security of a site through "brute-force" automated attacks on the password system. Most commonly, these attacks are performed using a dictionary of common terms and common passwords. It is always amazing to discover how many users use the word "password" or "1234" as their system password.
One method of promoting good user-selection of secure passwords is to encourage following these guidelines:
Make a password at least seven characters long.
Use uppercase and lowercase characters.
Include numeric characters.
Users should incorporate two words and a number in their passwords. If one of those words is non-English (perhaps even "Joomla"), the chances of a dictionary or brute-force attack succeeding are almost nil.
In Hollywood movies, "hackers" use techniques like the brute-force method to break into a single user's account, but real hackers are much less choosy. The majority of successful brute-force attacks don't vary the password as much as the username. Since the word "password" is so common, a hacker will run this password against a user list to see if anyone has an account with that key. Therefore, it is advisable to shield your user list from general access.
One of the most common and effective forms of Internet attack is the SQL injection attack. In an injection attack, a hacker attempts to send unauthorized SQL code through an unfiltered SQL query. The hacker's SQL code may do anything from return secure information to execute a destructive procedure.
With basic precautions, you can protect against this type of security breach. The basic rule of thumb for protection against injection is to ensure that your program code never trusts raw data passed from an outside process (even if that process is a form you've created). All raw data accepted from outside the system should be processed and validated before it is used by the application.
For example, an HTML form may accept a field for a name. While a normal user would enter a simple name into the field, the hacker injects SQL code into the statement that alters the execution of the query. If the PHP code for the query placed the entered name into the variable $name and queried with it, the code for the query string might look something like this:
$sql = "Select * From jos_users Where name = '" . $name . "';";
The hacker would simply enter a last name that read as follows:
dummytext' or 'a' = 'a
The SQL code generated from this value would read as follows:
Select * From jos_users Where name = 'dummytext' or 'a' = 'a';
When the query is executed, the 'a' = 'a' test would return a True value for every row, and the query would return the entire user list! Even scarier is that any valid SQL code can be injected, as shown here:
dummytext'; Drop Table jos_users; Select * From jos_polls Where title = '
That code would destroy the Joomla user table entirely. Sending the form input text through a simple processing routine would eliminate any danger from such an attack.
Joomla includes routines to generate escape characters for any characters that can't be properly stored inside a database string. For example, the single quotation mark (') cannot be stored without modification in a standard SQL Insert statement. Therefore, an escape sequence provided by the backslash () character on MySQL systems allows special characters to be included. Thus, a backslash followed by the quote (') would store the single quote in a database field.
Creating an escaped string from the user-supplied string invalidates the injection attack because the single quote is no longer taken as a literal character for SQL execution. Instead, the quote (and any code that was intended for injection) is simply stored as part of the string. The likely result of such a query string would be the return of an error, since no records matching that value would be found.
For straight PHP code, you can instead use a database-specific method of generating a string that creates escape codes for special characters. For MySQL, PHP includes the mysql_real_escape_string() function. It can be used to format a string like this:
$name = mysql_real_escape_string($name);
Joomla provides an abstracted method called getEscaped() that will return the escaped string regardless of the target database. Although Joomla presently only supports MySQL, in the future when further data sources are added, code using the Joomla method instead of direct PHP will still work properly. You can get the escaped string from the JDatabase object like this:
$db =& JFactory::getDBO(); $name = $db->getEscaped($name);
If the first example of SQL Insertion attack were escaped, it would generate the following harmless string:
dummytext' or 'a' = 'a
The second example would look like this:
dummytext'; Drop Table jos_users; Select * From jos_polls Where title = '
There is a feature in PHP known as "magic quotes" that will automatically add backslashes to all input fields received from an outside source (such as a Web browser). In version 6 of PHP, the magic quotes option has been eliminated. Therefore, it is better to code manual escape processing as shown so that your code will securely run on PHP servers in the future without modification.
Another form of injection attack can occur when values that are not typed (set to be an integer, float, and so on) are passed directly to the SQL engine. For example, an id value retrieved from a query string might be passed directly into a SQL query with a line like this:
$sql = "Select * From jos_users Where id = " . $id . ";";
The same type of injection code could be used as the unescaped string:
1; Drop Table jos_users;
Therefore, whenever you accept values from a query string or form posting, be sure to type them through PHP. For example, to type the $id into an Integer, you could use the following PHP code:
$id = intval($id);
Typing code will automatically either outright eliminate any Injection code included in the field, or will generate an error when the code makes the typing nonsense.
If you use the JRequest::getVar() or JRequest::get() methods to obtain form and query string data, you are already protected because these functions provide a secure filter of all incoming data. Any outside data not obtained through these functions, however, should be escaped and typed wherever possible.
SQL Injection attacks don't only come through form entry pages. Increasingly, Web sites are implementing Ajax technology that makes data requests of the system that skirt most common data-validation routines. That means that the explosion of Ajax use opens up a wide variety of potential security violation points.
Therefore, special attention should be paid to the portions of a system that provide responses to Ajax queries. When designing an Ajax responder, ask yourself the following questions:
Have I typed all of the request data? — Every piece of information that comes from the outside should be processed and typed. That will prevent nearly every basic kind of injection attack. Limits should also be placed on strings to prevent any sort of overflow bug from rendering your system vulnerable. No last name should be more than 50 characters, so why not trim the string to that length to prevent false entry?
Should I limit the scope of the data accessible? — For example, an Ajax component may provide a Who-Is display that shows the user's home country. However, the query is made off the entire contact table where a SQL Injection attack could possibly reveal personal information such as a home address. MySQL supports a table view that provides a filter for table data. By including only the data used by the Ajax component in the view, even a penetration would reveal no more than publicly available information.
Is this information you want to provide through Ajax? — Many companies make available through Ajax requests whole databases or catalogs. However, a simple program can be constructed to make sequential requests to the Ajax responder and harvest all of the information in the database. Ensure that you understand the data you will be exposing or a competitor may use your own database for his or her competitive advantage.
These are just a few of the considerations you should examine in this infancy of Ajax implementation. The new technology will likely cause a tremendous number of security breaches before the weaknesses of the system are understood and protected. When implementing an Ajax solution, be sure to read the most current security literature so that you can understand the newest hacker threats.
Cross-site scripting (XSS) is a method of inserting some executing JavaScript code or object references into HTML code when an HTML editor is made available to the user. This code may open a hidden window on the user's system and record items such as usernames and passwords entered into other browser windows. Since this vulnerability occurs when a site allows user-posted content (a cornerstone of Web 2.0 dynamic interaction), it is very dangerous and must be guarded against.
These types of attacks can be controlled when they are attempted through the Joomla user interface (see the section "Joomla Security" later in this chapter). However, the prevalence of available extensions that allow HTML code entry (from guestbooks to forums) means that you should be on the alert to prevent these types of attack. Ensure that any new extensions filter the tags used by this method of attack (chiefly <object> and <script>) before you deploy the extension on your site.
PHP has a few built-in functions that can help you. The strip_tags() function will strip all HTML, XML, and PHP tags from a passed string and return the raw text. This can be used very effectively if your application is not expecting rich text formatting as input. For formatting, you could use BBCode, which is left unaffected by this function.
The htmlentities() function in PHP will convert all non-alphanumeric characters (such as quotation marks, greater than signs, and so on) to HTML formatting. You can also use regular expressions to strip everything from input fields except alphanumeric characters. For a last name field, you might use a statement like this:
$myString = preg_replace("/[^a-z 0-9]/i", "", $myString);Many Web servers have the option set to allow directory browsing. Over an HTTP connection, a visitor can browse to a directory and see all of the files contained there, provided that there is no default.htm, default.asp, index.html, or index.php file found in the directory. Directory browsing is an open invitation for hackers to discover a great deal of information about your system. Everything from configuration filenames to general system information can be learned if that hacker has knowledge of the host applications and operating system.
By default, most Web servers now have this option disabled. If your site will be hosted on an older server, be sure to check that this directive is not set. This form of hacking is more likely to be performed manually by a hacker, since full knowledge must be used to recognize the weakness of a system.
As a preventative measure, Joomla includes a dummy index.html file in every site directory and subdirectory of the site to prevent this possible intrusion. Most extensions and templates, however, don't take this preventative step, as you should do with all add-ons that you create for the Joomla system.
The denial of service (DoS) attack is an attempt to deny use of a server or other resource to authorized users. The most common form of this attack simply floods a router or server with so many requests that the machine is overwhelmed and cannot respond to authentic requests. In another common DoS attack, an attempt is made to force a reset of the server or router, which makes the resources unavailable during the restarting process. Of course, once the reset is complete, the attacker requests another reset and continues to repeat this process.
To prevent tracking of the hackers and also to reach a critical mass of false requests, the DoS attack is often launched with a virus or worm that spreads the attacking code to innocent computers. This is known as a distributed denial of service attack. At a particular time and date, the code activates and previously friendly computers simultaneously attack the target.
Most DoS attacks must be deflected at the hardware level, so if you are running the host server, be sure to have a good firewall in place. Special firewalls known as stateful firewalls will automatically recognize the difference between good traffic and DoS traffic, and will prevent the invalid traffic from being passed onto the network.
The OpenBSD packet filter program called pf supports a feature called synproxy that sits between a server and Internet traffic. It performs the same role as a stateful firewall in blocking faked traffic. You can find more information about pf at www.openbsd.org/faq/pf.
The nature of Web communication means the information sent and received is broken down into small chunks of data called packets and broadcast over the Internet. The packets eventually find their way from the broadcast computer to the target computer, passing through a variety of computers and routers before they reach their destinations. This makes it possible for a computer sitting somewhere between the broadcaster and the target to copy or "sniff" the packets that pass by.
Web data is sent and received in HTTP format encapsulated within packets. An HTTP Sniffer (EffeTech HTTP Sniffer, for example) gathers and decodes packets containing information in the HTTP protocol. The sniffer then rebuilds the HTTP session and can open files and data that it intercepts.
For a Joomla site (or any other site that has an unencrypted login), an HTTP sniffer can potentially intercept entered username and password information. For an Internet deployment of Joomla, it is fairly unlikely (and very difficult) to place a sniffer inline to make such interception possible. On a Joomla intranet run on a local area network, however, the opportunities and penetration points are greatly increased.
In those circumstances, you might consider purchasing an SSL security certificate to allow encryption of traffic between a browser and the Web server. Check out the Verisign Web site (www.verisign.com) for a complete explanation of how the certificates work and the way they provide encryption of data. Once you have an SSL certificate installed on your Web server, you should be able to access it with a URL like https://www.example.com. The https:// address stands for "HTTP secure." The default port used by https:// is 443 instead of port 80 for the normal Web interaction.
If you want all site interaction encrypted, you merely need to point the Web server at the Joomla root for the server location default. However, you can use Joomla's switchover technology, which lets you switch between secure and insecure versions of a Joomla site. That way pages for login, registration, personal information entry, e-commerce, and perhaps even Administrator interface access can use an encrypted communication while the rest of the interaction with the site is unencrypted.
To enable a secure login on a Joomla site, first you must have the SSL active on your Web server. Then, you must unpublish the Login module so that there is no insecure login available. Create a new menu item that will provide the link to display the login screen under the SSL encryption. It needs to address the User
When the menu item screen is displayed, set the Title to Login. Expand the System Parameters frame, and set the SSL Enabled option to On, as shown in Figure 14-2. This option will make the link from the menu begin with an https://.
That's it! When the user clicks on the link from the front page, the login screen will be displayed as shown in Figure 14-3, and the small padlock in the bottom of the browser window will be locked, showing that the site is secure.
The lowest level of attack and least likely place for penetration is the Web server. Both Apache Web server and Microsoft IIS are hosting literally millions of Web sites with few publicized breaches. Although such widespread adoption doesn't prevent the possibility of a security problem, the servers are very well debugged and protected.
Apache is even less likely to be the vector of an attack, since the execution of Web scripts (such as PHP or Perl) is not handled by the Web server itself, but rather a plug-in or component. Since script execution engines are perhaps the most directly vulnerable to attack, the Apache Web server itself does not have this point of jeopardy.
Apache Server, out of the box, is extremely secure. Since Apache runs a large chunk of the Web servers of the world, it has been tested and probed from every which way. Therefore, without any changes to the configuration settings, a vanilla Apache install will handle most security needs.
Nonetheless, there are a few places where you can add a little extra safety. Although Apache is very secure by default, it can easily be made insecure by a poor setting choice. Therefore, be sure to give careful consideration before you edit any of the default settings.
With Apache server, the file and folder permissions can be stored in a file called .htaccess. Access permission, password protection, PHP blocking, and other security settings may be specified in the file. Because of the power available through the file, Apache includes (by default) a configuration to make the file inaccessible from outside the system through a browser.
Joomla users generally use the .htaccess file to set the permissions to allow the use of mod_rewrite to create Search Engine Friendly (SEF) URLs (see Chapter 13 for more information). The Joomla installation includes a usable htaccess file named htaccess.txt that you can activate for mod_rewrite enabling if your system is not currently set up to use it. To activate it, simply rename the htaccess.txt file to .htaccess instead.
On Windows, the Explorer file interface will not allow you to rename a file to an empty filename with an extension (which is how
.htaccessappears to the system). You can either add a directive to thehttpd.conffile to look for the access file under a different name or you can open the command prompt window and use therencommand.
The more information a hacker obtains about your system, the more exact the methods that he or she can use against your site. While it will be fairly obvious to the beginning hacker what type of Web server you are running, providing extra information such as the version number, operating system, and so on, is not in your best interests. Unfortunately, much of this information is provided by the ServerSignature whenever the server generates a page (such as a server error message).
Adding the following directive to your httpd.conf file will turn off the signature output:
ServerSignature Off
Much of the information supplied by the signature is also returned with every page request. The ServerTokens directive lets you set the amount of information about the server to provide with the page request. There are six settings available for this directive. In descending order, these include Full, OS, Minimal, Minor, Major, and Prod.
You should add a directive to provide the least information, like this:
ServerTokens Prod
A helpful security feature included in Apache is the capability to deny access to particular types of files from a Web browser. By using this capability, you can deny outside access to any file types that have no reason to be addressed by a browser (such as .log files).
Your default httpd.conf file should contain an entry to deny a browser access to the .htaccess file. Examining the configuration file, you should see code like this:
<FilesMatch "^.ht">
Order allow,deny
Deny from all
</FilesMatch>This code tells Apache to deny browser access to all .htaccess files (and .htpasswd files, too). To deny access to log files, you can copy the previous section and then modify the FilesMatch statement like this:
<FilesMatch ~ ".log$">
To deny browser access to a particular directory, you need to use the Directory element like this:
<Directory ~ "C:/Program Files/Apache Software
Foundation/Apache2.2/htdocs/libraries">
Order allow,deny
Deny from all
</Directory >When a browser attempts to access files in the libraries directory or any directory inside it (existing or not), a 403 Forbidden Page error will be returned.
PHP security will likely be the most important server technology to secure because it is the most vulnerable to attack and also has a number of administrative configurations that can open security holes. If an attacker can successfully execute script code outside narrow limitations, there is great potential that the villain can take complete control of the system.
The first step in minimizing potential jeopardy to your system is ensuring that there are no files on your server that call the phpinfo() function. While this function is superb for examining your system and determining configuration settings, it can provide a hacker with a complete window into your PHP system. That information can give clues on exactly how a breach might be accomplished.
After you have made sure that your server doesn't expose itself, there are a number of PHP directives that can seal up the server to ensure that it isn't a promising target for the visiting hacker. Although a Joomla server can function correctly without these security precautions in place, you will potentially save yourself a lot of grief if you ensure that your Joomla server is securely configured.
In PHP version 6, three common features (register globals, magic quotes, and safe mode) have been eliminated. In the case of magic quotes (see the section "SQL Injection" earlier in this chapter), the removal of the feature will require novices to pay closer attention to their coding.
When safe mode is activated on a Web server, execution scripts can only access files within their own Web site directory. This prevents hackers on a shared system from executing a script in one directory that can read files and information from a directory that doesn't belong to them. Safe mode also limits script execution time, memory utilization, and access to certain system functions (such as exec(), unlink(), and copy()). It is good to have safe mode turned on in many situations, although some programs and components won't function completely if this mode is enabled.
Safe mode is activated on most shared remote PHP hosts. You can check if the mode is set to On by executing the phpinfo() function and looking in the Configuration
If you are running PHP on Microsoft IIS, you do not need to use safe mode, since each virtual host can be configured to run from a separate user account. As long as the privileges of the user accounts are properly set, there is no need to prohibit cross-account access because it will not be possible.
Safe Mode is removed in PHP version 6 and above. The restrictions it provided are thought to give a false sense of security. From its initial implementation, it was a stopgap measure until Web servers (where the problem should be handled) had reached a level of sophistication where it would no longer be needed. Servers have been at that level for some time.
The doc_root directive accepts a string that specifies the execution root directory for PHP scripts. If safe_mode is enabled, then no scripts will be allowed to execute outside of the cited directory. The directory should be set in the php.ini file like this:
doc_root = "C:Program FilesApache Software FoundationApache2.2"
With PHP safe mode deprecated, there are a number of other functions that can be used to secure individual items in PHP. For example, the disable_functions directive can be set to deactivate particular functions that might be exploited by a hacker. In your php.ini file, inserting the following directive will deactivate the functions listed without affecting Joomla's operation:
disable_functions = file,fopen,popen,unlink,system,passthru,exec,popen, proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec
On a deployment server, you may consider including the phpinfo function in the disable list. That way, if any errant files exist that call the function, even if a hacker locates that file, it can't be exploited for the information it would supply.
Before you make this sort of configuration change, ensure that you understand PHP fairly thoroughly. Otherwise, you are likely to disable a function that is used by an extension, and thereby limit the functionality of your Web site.
Like disable_functions, the disable_classes directory accepts a comma-delimited list of items to be disabled. This function will deactivate the specified object-oriented class from executing under PHP. While this directive has only limited usefulness as of this writing, in the future, when class frameworks (including the Joomla framework) become more extensive and present security risks, this setting will prove very useful.
To disable the Directory class, include this directive in your php.ini file:
disable_classes=Directory
One setting that you will almost certainly want turned on when using a staging server and definitely want off on a deployment server is the display_errors setting. When this is enabled, any errors or warnings that occur during PHP execution are echoed to the browser, along with the file and line number where the error occurred. You can enable this option in the php.ini file with this directive:
display_errors = On
During development, you will want all errors displayed to allow fast resolution, and all warnings displayed because they will tend to be overlooked if they are only entered into the error logs. With this setting disabled, the messages from the system will not be lost. Whether activated or deactivated, errors and warnings are written into the error.log file of the logs directory on an Apache server as long as log_errors is left enabled (which is the default).
Be sure to set this parameter to Off on a deployment server. If left on, any error can provide a hacker with a variety of information about your Web server, including filenames, directory paths, variables, and permission settings. These may be exploited to provide unauthorized access or damage to your site.
The Apache ServerTokens mentioned earlier sends server information with each page request. The expose_php directive will append information about the PHP server to the information returned during a page request. By default, this option is enabled, but for best security, you should disable it on your deployment server.
To deactivate the supply of the PHP server information, set this directive in your php.ini file:
expose_php = Off
The MySQL database server can hold a great deal of important private information. If the Joomla platform is used for contact management or eCommerce, the potential access to user's private identity information can be substantial. Therefore, you should read the brief (but significant) MySQL "General Security Issues" guide that you'll find at the following URL:
http://dev.mysql.com/doc/refman/5.0/en/security.html
The Joomla system is created to provide a great deal of turnkey security, so even a default installation will be fairly secure. However, there are a number of fine adjustments that you can make to tighten up a few Joomla weak points. New security problems arise all the time as hackers devise new methods of breaching security. You should always keep your Joomla installation updated to the most recent available version.
The best method of staying informed about possible Joomla security issues is to subscribe to the Joomla "Security Related Announcements." You will receive emails relating security information and any alerts that require special attention. To subscribe, search on the Web (in case the location has changed) or go to this forum topic:
http://forum.joomla.org/index.php/topic,125221.0.html
Be sure that, once you have completed installation, you delete the installation folder and all of the files in it. If a hacker were able to reactivate the installation process on an existing server, it would be possible to wipe the site clean. To make sure this doesn't happen under any circumstances, be sure the installation execution files are removed from your Web server.
If you allow contributors on your Web site, there is the potential of someone using an account to attack the system through an XSS attack, as described earlier in this chapter in the section, "Cross-Site Scripting (XSS)." Be sure to limit the capabilities of the editors that are available to contributors.
Through the Plugin Manager, you can access the parameters for the rich text editors used by Joomla. These editors nearly always contain functionality that allows automatic stripping of potentially hazardous content from user-entered content.
TinyMCE can strip security risks found in articles through the "Code Cleanup" and "Code Cleanup on startup" options (see Figure 14-4). By default, Code Cleanup is set, while the startup option is not. You only need the startup option if you believe there is already unclean code in you article database.
There are certain conditions where the Code Cleanup function will prevent you from doing something you want to do (such as inserting a YouTube video into an article) because it thinks the code is dangerous. Rather than disabling the option, select the No Editor option and edit directly in HTML when making changes to articles that have such content.
A more powerful setting on the TinyMCE parameters screen is the Prohibited Elements setting that allows you to specify HTML elements that can be stripped from the entered text. By default, only applet is entered in this field. For greater security, you might consider setting the list to object,applet,iframe, which will prohibit almost all element types that might be used for XSS attacks, among other things. Of course, it will also stop users from adding Flash animation and other dynamic content.
When a hacker can directly execute a PHP file from outside the system, all sorts of mischief is possible. If you are developing new extensions (modules, components, or plug-ins), always add the code that ensures that the extension is being run by Joomla itself. At the top of your code file, add the following line:
defined( '_JEXEC' ) or die( 'Restricted access' );
If the _JEXEC parameter is not defined (meaning Joomla isn't executing the process), the execution of the code terminates. Even a primitive test extension should include the line just in case it is left installed on the server and forgotten, only to be found later by a hacker and exploited.
If you are going to deploy a protected Joomla system, you must be able to test configurations and extensions on a safe system. This testing should all be done on a staging server. The staging server can be fairly insecure and include all types of rough extensions and code.
A staging server is even more important for security if you are performing development. Test scripts and example extensions are only two of the items that you will need to execute when performing development that can create large gateways of opportunity for a hacker to enter. Attacks generally occur at a system's weakest point, and a development system will have many.
Once development is complete, you should move the configured system to a deployment server. You should not move the configuration files such as php.ini and httpd.conf because the deployment server should have vastly different settings. When certain portions of the system break under the new stricter deployment (and they will), track down the problem instead of disabling the problem setting. This will lead to a stronger Joomla deployment and more solid code.
Joomla is intrinsically a very secure system. And yet, its coordination of multiple Web technologies makes it vulnerable unless security threats are understood and proper countermeasures put into place. This chapter has provided an overview of the ways Joomla security concerns can be addressed by doing the following:
Understanding the types of attacks that can be attempted against a Web server.
Improving the security configuration settings of the Apache server.
Refining the
php.inifile to limit execution and access.Creating a MySQL security policy to prevent unauthorized information access.
Configuring Joomla parameters to best prevent potential attacks.
Security from outside attacks is very essential, but having effective control of user access within a system is very important as well. Unfortunately, this area is one that is somewhat lacking in Joomla. Chapter 15 examines all of the areas where Joomla lacks capability that is included in higher-end CMS systems.