1. Introduction
The Internet is more alive than ever: the number of websites on the Internet has already exceeded one billion [
1], the number of Internet users has achieved almost four billion [
2], and the penetration rate is more than 51.7% [
2]. By observing the growth trend during recent years (see
Figure 1), we could come to the conclusion that this evolution is entering a permanent phase, i.e., a linear instead of an exponential increase. However, if we check other statistics, we find that 60% of Small and Medium Businesses (SMB) do not have a corporate website [
3]. As a consequence, there is still much room for growth, and Web Content Management Systems (WCMS) facilitate this task. WCMS are software platforms generally used when a website is needed, commonly requiring different user roles, but when at the same time there is a lack of web programming knowledge [
4,
5,
6,
7]. As a tool, WCMS are booming, being very helpful for beginners in web development or for small business managers, because websites can easily be implemented at a relative low cost [
8,
9]. One example could be a newspaper editorial, where journalists are interested in launching an online edition. In this case, journalists may not know enough about web programming to develop their website, having only office software skills. It is in this scenario that WCMS have great potential. The
open-source WCMS, also called second-generation WCMS, are platforms often based on PHP (PHP Hypertext Preprocessor) and usually fed by communities of users who contribute novel solutions and new functionalities [
11]. The basic WCMS structure has the following parts: (i) the files of the content manager; (ii) a hosting provider to store the files of the content manager; and (iii) a linked database, e.g., MySQL (My Structured Query Language), to store website information. A WCMS provides an administration or development area called the
back-end, where articles, functionalities, or any other aspect can be added, deleted, or modified. On the other hand, the visible part of a website, i.e., what a visitor
sees, is called the
front-end.
Security vulnerabilities are a weak point of any system at the design and implementation levels, and WCMS are not an exception [
9]. Bugs and flaws are both software problems differing in terms of the level at which they are presented (implementation and design, respectively); in any case, they are dangerous, and should be analyzed [
12]. In a simplified way, an attack consists of two phases: discovery, which is longer in time, and exploitation, once the weakness of the WCMS is known [
13]. A secure application ensures authentication, confidentiality, integrity, and availability. Depending on the service we are focusing on, we could put aside some of these security characteristic (e.g., confidentiality). However, WCMS are a key piece of today’s Internet, and have become a target for attackers [
14,
15]. If a WCMS has security vulnerabilities, it may become inaccessible [
16], with the corresponding negative effects. Usual attack consequences are: confidential data destruction, data modification, misuse of a web-server for illegal activities, and Denial-of-Service (DoS), among others.
Due to the key position that WCMS occupy in today’s Internet, and the security concerns that can arise with an inappropriate use or configuration, the goal of this article is twofold. Firstly, we extend the work carried out in [
17], explaining how to manage a WCMS from a tutorial perspective, and what can be achieved with its use. In order to do so, we have chosen the best WCMS in terms of popularity and performance [
18,
19,
20,
21]; namely, WordPress [
22], Joomla! [
23], and Drupal [
24]. Regarding popularity, while only 23.6% of web pages were created with a WCMS in January 2011, this figure increased to 48.8% in January 2018 [
19]. In 2011, 13.1% of the websites were implemented with WordPress, 2.6% with Joomla!, and 1.4% with Drupal. In 2018, the most used WCMS is WordPress (29.3%), the second preferred option is Joomla (3.2%), and the third one is Drupal (2.3%). In other words, WordPress has a market share of 60% in January 2018, followed by Joomla! and Drupal with 6.5% and 4.6%, respectively [
18]. In terms of performance, the works done in [
20,
21] compared several WCMS and both studies emphasized that WordPress, Joomla!, and Drupal were the most efficient ones, because they achieved a better load time and good static content, showed the highest number of installations, presented better documentation support, etc. Although Joomla! and Drupal have lost some relevance, they are still widely used as shown in [
25], what justifies choosing them for this comparative work. The methodology followed for the comparison consists of creating three equal web sites, each one with a different WCMS. The advantages and drawbacks of each selected WCMS, as well as their complexity, will be discussed. Secondly, we carry out a basic security analysis of each implemented website, reporting vulnerabilities, how to bestow security on them, which mistakes can be avoided, and which WCMS is initially safer.
The rest of the paper is organized as follows.
Section 2 includes the related work. In
Section 3, all details about the selected WCMS are discussed.
Section 4 provides a guide to how to create a website using Joomla!, Drupal, and WordPress, as well as a qualitative comparison.
Section 5 presents the outcomes of the basic security analysis. The document ends with the conclusion.
4. Creating a Website with Joomla!, Drupal, and WordPress
To compare the three WCMS under study, and to provide a good understanding of their operation, the same website is going to be created using Joomla!, then Drupal, and finally WordPress. The website should follow the graphical distribution shown in
Figure 2 and should have the functionalities enumerated below:
A homepage slider or banner, based on JavaScript.
A login module, allowing user registration and creating private areas on the website.
Social network integration; Twitter and Facebook.
A multi-language module, content translation based on Google Translator.
A search module, to find indexed content in the website.
A contact form.
Videos.
Maps.
A downloads section, customized multi-user downloads.
A newsletter, so users are aware of recent news by mail
Events, as a way to place important news into the website homepage.
The first step in starting the website implementation is the installation process. In order to do so, the recommended steps are the same for all WCMS:
Hire a hosting provider service (e.g., 1and1.com) that includes a database (e.g., MySQL).
Create the WCMS database.
Download the WCMS installation package from the official website and extract the files into the virtual directory given by the hosting provider.
Install the WCMS using the installation wizard, which links with the database.
On the other hand, the WCMS configuration and customization process usually follows the next pattern. Firstly, it is necessary to download or to design the website template, e.g., with a template editor such as Artisteer [
33]. Then, the template should be assigned to the website, for instance using the template manager. Secondly, it will be necessary to look for extensions to add the required functionalities. Once found, these extensions need to be enabled and located on the website. Before setting up the template, it is important to check available sections or areas so that those functionalities will be placed in the desired position. Finally, content should be added using the provided editors. Each WCMS usually has its own editor tool for inserting multimedia content or text.
Table 5 summarizes the similarities and differences found during the implementation of the websites using Joomla!, WordPress, and Drupal. The Yoo Downtown template was selected for Joomla! and WordPress, whereas the AT commerce template was chosen for Drupal. Note that the selected templates incorporate their own framework for changing block positions and size, page width, fonts, colors, etc. This is highly useful, because it allows a high level of customization, and therefore, a similar visual aspect can be achieved with the three WCMS. Artisteer [
33] is a software tool whose goal is to customize the website in a very intuitive way, modifying the visual aspect as required. Once the changes have been done, the user can export the template as a .zip file ready to be installed in the web-content manager. Regarding header and footer, the Artical module for Joomla! transforms an article made with the editor into a module to be placed wherever the designer considers appropriate on the website. Drupal and WordPress natively integrate this option.
A home-page slider is a good choice for implementing a website with an attractive look. The slider with Drupal needs an additional library called
jquery.cycle.all.js to work properly. With WordPress, it is necessary to include the returned configuration code into the post (or page) to show the slider. For both WCMS, the picture dimensions and the route where the pictures are located need to be set. On the other hand, Nivo [
34] is the module used to incorporate the slider into the Joomla! website. Regarding the social-networks buttons, there are websites such as Linksalpha [
35] that return the necessary code to be inserted into a new website section, which has been very useful with Drupal and WordPress. As before, Joomla! does not share the same implementation process, opting in this case for the ITPsocialbuttons module [
36]. As expected, when users click on one of these buttons, they will be forwarded to the corresponding social network account to publish a website recommendation. Focusing on the web users, they should be able to choose the website language (for all web content). To do so, we have employed the Google Translator [
37] module. By using this module, it is only necessary to indicate which languages will be offered and the default website language. Google Translator is widely considered a powerful tool able to provide a desirable service in the three WCMS under study. Multimedia resources are needed to build an appealing website. The easiest method to insert multimedia from YouTube, Twitter, or Maps is pasting the embedded HTML code provided by official websites into the corresponding website section. Other modules included by default in the website kernel are search and login, with each WCMS having its own implementation. It is highly recommended to read the documentation before implementing the module for each platform.
Events and events management are also of interest in our website. Each WCMS uses a different module or widget to incorporate the events. The Joomla! module has been configured in a way whereby it is possible to select which article identifiers should be highlighted as the most important ones. WordPress uses a permanent link widget to paste the links for interesting events; please note that when a new page is created in WordPress, a permanent link is always returned. However, Drupal uses a so-called
recent content section to manage which pages from the website are also going to be considered as events. The download manager tool employed by Joomla! is Jdownloads [
38]. Mailchimp [
39] is the chosen method to create the newsletter on WordPress, Joomla!, and Drupal. Mailchimp websites return predefined code text to be inserted into the website; hence, users can subscribe to the latest news via e-mail. The contact form is the section that requires more configuration and customization because labels, text-boxes, text-areas, submit, and reset buttons should be implemented, as well as setting configuration parameters, such as the e-mail recipient of the queries. We decided to exchange the default Joomla! editor for one more comprehensive and complete, which allows multimedia integration; namely, JCE. Finally, the corresponding articles are selected to appear on the homepage of the three websites. Based on this work, and from a qualitative perspective, Joomla! offers the most intuitive solution in terms of content management administration and functionalities, Drupal presents the highest complexity in management, and WordPress has the advantage of providing functionalities from its own back-end.
5. Basic Security Analysis
As we mentioned in
Section 1, WCMS are becoming a common target for attackers, raising important security concerns. Possible WCMS threats are [
40,
41]:
Data manipulation: violating data integrity, e.g., Structured Query Language (SQL) injection and parameter manipulation.
Confidential data: when an unauthorized person has access to sorted data, e.g., SQL injection and Cross-Site Scripting (XSS).
Phishing: a special confidential data-gathering method using forms and spam mails.
Spam: using email addresses published on the website.
Execution of code, run scripts, or programs on a web-server using WCMS vulnerabilities.
Analyzing the information shown in
Figure 3 [
42], JavaScript and PHP are the programming languages with the most vulnerabilities, generating a high amount of security weaknesses. Technologies and frameworks based on Java are less vulnerable; in cases of vulnerability, this is usually because of poor component or framework patching. Packages such as JQuery in PHP and JavaScript are also a source of vulnerabilities. Despite being the most used web-server software, Apache [
43] can present several vulnerabilities due to poor configurations and patching policies. At the application layer, 61% of attacks are made through a web-browser. 86% of those web-browser attacks correspond to an XSS attack, thus constituting a vast majority. In an XSS attack, a mischievous user finds a means to insert a malicious code fragment into the website [
16]. That is, an XSS attack injects a malicious sequence of commands into a trusted website executed on the visitor’s web-browser (without the visitor’s knowledge), and therefore, the attacker has access to sensitive user data, such as session tokens and cookies, stored in the browser [
44]. Some variations of the XSS attack are the following:
Reflected XSS attack: This attack uses other routes to reach the victims, such as email messages with crafted links or other websites, which reflect the attack back to the user’s web-browser. The script is executed by the web-browser because it comes from a “
trusted server”. This type of attack is also known as
Non-Persistent or
Type-II XSS [
45].
Stored XSS attack: The malicious script is stored somewhere on the web-server (e.g., a database, a forum message, logs, comments, etc.) and is sent to the victim when it requests the query. This attack type is also called
Persistent or
Type-I XSS [
45].
DOM-Based (Document Object Model)
attack: In contrast to previous types, in this one, the injection is performed by the user into the web-page when the server script processes user data and injects it back into the website [
46].
Another common attack is SQL injection [
47]. In this case, a malicious user accesses a website database, and is able to modify it. Databases are fundamental for implementing websites using WCMS. Databases store large volumes of information, in many cases valuable information, and are a common target for malicious users. To perpetrate an SQL injection attack, the website must have an input to write an SQL query. Then, the website should include the attacker input data as an SQL statement into the application without any verification, so this statement could be an SQL query and be run against a database server [
48,
49]. If the attack is successful, confidential and sensitive data could be read, modified, or even deleted. Moreover, the attacker could execute administration operations on the database and obtain the database structure information. SQL injection errors occur when the executed program is from a non-verified source or SQL queries are formed dynamically [
47]. While an SQL injection is directed to the query function that interacts with the database, XSS attacks take advantage of the output HTML function that sends data to the browser. In any case, most attacks can result in a total system-wide compromise [
42].
In this scenario, there are several security recommendations that should always be followed when working with WCMS:
Make regular WCMS backups (files and database).
Hire professional hosting providers, which are safer against SQL injection attacks.
Use the most recent versions of WCMS and plugins.
Employ specific security plugins, such as JHackGuard for Joomla!, that provide extra security.
Limit the access to administration files and folders.
Remove the installation script (install.php on Drupal and installation folder on Joomla!).
Modify default passwords and define safe user roles.
Enable captcha for unregistered users avoiding spam.
Hide email addresses to avoid unsolicited spam.
Activate URLs-friendly.
Change the default global website parameters configuration.
Change the default database prefix during the installation process (if possible).
Avoid showing sensitive information about the WCMS in the front-end.
Nevertheless, complying with these suggestions is not enough. Vulnerability assessment and penetration testing, a process also known as
pentesting, have become a valuable tool for evaluating security in a wide variety of systems and devices by simulating attacks. More specifically, the aim of a vulnerability assessment is scanning, i.e., to perform network discovery, network port, and service identification for a system or device, trying to find inadequate security measures and vulnerabilities. On the other hand, penetration testing goes a step further, being defined by the National Institute of Standards and Technology (NIST) as the tester being able to “simulate the actions of a given class of attacker by using a defined set of documentation (i.e., the documentation representative of what that class of attacker is likely to possess) and working under other specific constraints to attempt to circumvent the security features of an information system” [
50]. Depending on the previous knowledge that the tester has about the target, three pentesting categories can be identified; namely, white-box, gray-box, and black-box testing. The
color of the test is inversely proportional to the amount of knowledge the tester has about the system being evaluated. For instance, in a black-box test no knowledge is assumed about the implementation or configuration of the target, whereas in a white-box test a high amount of information is known (e.g., operating system, source code, etc.).
In this work, we performed a basic security analysis on the websites implemented with Joomla! and Drupal. The website implemented with WordPress was not included in this preliminary analysis, and was left for future work. To carry out the security analysis, we used the Acunetix software [
51], an intuitive and automated tool for auditing website security. Acunetix automatically crawls the specified website, carrying out both black-box and gray-box hacking to discover threatening vulnerabilities that can compromise a website and its data. The testing process was as follows. We employed Windows as our operating system. Once Acunetix was installed, the first step was choosing the option
New Scan, and the program launched a wizard to enter all the testing configuration parameters, e.g., scan type, target, crawling options, scan options, and login. In the scan type window, we opted to scan a single website and introduced the website URL. In the second step, we added some information about the target, such as operating system, web-server, server banner, etc., although most parameters were automatically completed. The crawling configuration was set by default in this scan. In the Scan Options section, we selected the scanning profile with a list of vulnerabilities that the target will be scanned for; in our study, this was XSS and SQL injection. The selected scanning mode was Heuristic, enabling Port Scanning and AcuSensor Technology. The Login section asked about HTTP or HTML authentication to login and scan the protected site. It was necessary to show the scanner how to log in to the website protected area with a username and password. In the last stage of the scan wizard, we could check the scan summary with the scan profile and target information. Once we clicked on finish, the scan was carried out and a complete report was obtained.
The results attained for SQL injection and XSS are shown in
Table 6. Analyzing the obtained results, Joomla! and Drupal present low or very low risk, unlike the outcomes obtained in [
16]. Testing SQL injection in the website developed with Joomla!, there were 133 total alerts, and their risk level was low or 1; whereas testing XSS, we obtained a total of 122 alerts with the same risk level. In contrast, the website implemented with Drupal presented fewer alerts (78 for SQL injection and 9 for XSS) with a similar risk level. Therefore, all alerts were low-risk warnings, and were similar in nature. Most of them corresponded to content, links, or extensions that had been deleted or uninstalled from the WCMS during the project development and, because of that, the content appears as non-indexed. In that case, Acunetix recommends removing it manually. On the other hand, tests showed a login module alert, since the auto-complete option is enabled, and Acunetix recommends disabling it. Lastly, results for Joomla! indicated that the
Jdownloads extension allowed users to upload files, which could be a dangerous action. However, this was a design requirement for our website.
In addition to the information gathered with the security test, there are other factors that have an effect on our website security. Both Joomla! and Drupal have a large and active user and developer community, always ready to include security enhancements into available versions, and also to report errors and potential solutions to solve system deficiencies and vulnerabilities. New versions of Joomla! and Drupal correct the errors and vulnerabilities of previous versions. However, both WCMS should give more recommendations to be followed during the installation process, specifically regarding critical folders and files to protect a posteriori; above all, a special emphasis should be placed on stating clearly that it is not secure to use the default admin user and the default database prefixes. Instead of this, the documentation (usually) only recommends deleting installation files after the installation process. Joomla! and Drupal have third-party additional modules developed to bestow extra security on websites. One example of such modules is the Taxonomy Access Control, which provides extra security by employing different user roles. Another example is Marco’s SQL Injection module for Joomla!, which protects against SQL injection and website file inclusion. Indeed, both WCMS have directives against SQL injection and XSS attacks. Additionally, they have an internal recognition system for checking the uploaded files extensions. Similarly, all the implemented structures and APIs are protected against XSS. Furthermore, third-party components or modules can be set to allow website visitors to upload files such as contact forms, a download manager, photo galleries, etc., having their own security configuration measures ranging from using captcha to filtering website visitors by IP address. These modules always register warnings in the general log, because they are external to the WCMS and thus may have some incompatibility, system update, or modification as a result of the version of the module. In addition, these modules and components usually notify the available updates. It is always recommended to update them, so many problems can be solved (or avoided), and the performance can be enhanced. Another security measure is spam protection to avoid malicious users or machines attacking the website using this technique. In particular, Joomla! has a weak point in the new user registration process, and Drupal recommends the use of captcha in this situation. Lastly, Drupal alerts should be disabled; otherwise, the security weaknesses will be shown. This is not a problem in Joomla!, because warning information is not reachable by website users.