The ‘WEBSITE HACKED TREND REPORT 2016-Q1‘ published on sucuri.net reported that data collected from 11000 infected websites and analysed by the Sucuri Remediation Group (RG) found that 78% of these sites were on WordPress.
With a glaring 78%, the first and deep impression over everyone is that WordPress is definitely more prone to hacking as compared to other CMS. However, is this true? It’s not.
The following is extracted from the above report:
“In most instances, the compromises analyzed had little, if anything, to do with the core of the CMS application itself, but more with improper deployment, configuration, and overall maintenance by the webmasters and their hosts.”
“In all instances, regardless of platform, the leading cause of infection could be traced to the exploitation of software vulnerabilities in the platform’s extensible components, not its core. The impacts to the WordPress stems from vulnerability exploitation attempts against vulnerability software, specifically in plugins. The three leading Software vulnerabilities affecting the most websites in the first quarter were the RevSlider and GravityForms plugins, followed by the TimThumb script.”
This report has led me to dig deeper into understanding WordPress software core, its security processes and inherent security that were built into the software. I wanted to know what contributed to the seemingly higher incidences of hacking attributed to WordPress. Is the core software lacking in in-built security or is that hackers are choosing to hack WordPress because of its popularity or it is simply its high market share that naturally contributed to its higher share of hacking incidence?
The Big Gap in Marketshare – WordPress versus all other CMS
Base on a research by W3Tech.com, WordPress has an estimated 60% of the content management system (CMS) market share, out of about 340 CMS available in the world and it is the fastest growing CMS base on the latest data in August 2016.
The grey bar in the above chart meant that of all the websites in the world, there are 55% that do not use CMS. The green bar is the CMS market share. Hence, of 45% sites that uses CMS, WordPress’ market share is almost 60%%. The next in line is Joomla with only 6% of market share.
When I first began to learn website development, I was comparing WordPress with Wix and Joomla. I built websites with all the three but I soon fell in love with WordPress because of the infinite possibilities that it enabled and the ever increasing beautiful themes that we can easily switch from one to another. It’s all so magical.
Having had developed many websites using WordPress, I am not surprised that it is the most popular CMS. However, is WordPress secure? Let’s look at WordPress software core.
WordPress Software Core and OWASP compliance
The following is quoted from WordPress.org on this subject of Security:
“Since its inception in 2003, WordPress has undergone continual hardening so its core software can address and mitigate common security threats, including the Top 10 list identified by The Open Web Application Security Project (OWASP) as common security vulnerabilities”.
For companies in Singapore where the government has set up Personal Data Protection Commission (PDPC), the guidelines provided to companies is to use OWASP testing guide to verify that security requirements for their website has been met. Hence, let’s examine how WordPress is meeting the 2013 OWASP Top 10.
The Open Web Application Security Project (OWASP) is an online community dedicated to web application security. The OWASP Top 10 list focuses on identifying the most serious application security risks for a broad array of organizations. The Top 10 items are selected and prioritized in combination with consensus estimates of exploitability, detectability, and impact estimates.
The following sections discuss the APIs, resources, and policies that WordPress uses to strengthen the core software and 3rd party plugins and themes against these potential risks.
A1 – Injection
This first item looks into injection flaws, such as SQL, OS, and LDAP injection that occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorisation. What did WordPress do about handling such injection flaws?
WordPress has provided a detail and comprehensive WordPress Plugin Handbook for developers and in this handbook, there is a section that covers Plugin Security. The section on Plugin Security documents and explains how to check user capabilities, validate and sanitize input, sanitize output and create and validate nonces. A set of functions and APIs are available in the Plugin Security documentation to assist developers in making sure unauthorized code cannot be injected, and help them validate and sanitize data.
A2 – Broken Authentication and Session Management
When application functions related to authentication and session management are not implemented correctly, it allows attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.
When you study in detail how WordPress implements authentication and session management, you will find that it has been carefully thought out and designed to ensure tight security. Wordpress core software manages user accounts and authentication. Details such as the user ID, name, and password are managed on the server-side, as well as the authentication cookies. Passwords are protected in the database using standard salting and stretching techniques. Existing sessions are destroyed upon logout for versions of WordPress after 4.0.
A3 – Cross Site Scripting (XSS)
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
As an example, the WordPress core team noticed before the release of WordPress 2.3 that the function
the_search_query() was being misused by most theme authors, who were not escaping the function’s output for use in HTML. In a very rare case of slightly breaking backward compatibility, the function’s output was changed in WordPress 2.3 to be pre-escaped.
A4 – Insecure Direct Object Reference
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data. So how does WordPress manage this?
WordPress often provides direct object reference, such as unique numeric identifiers of user accounts or content available in the URL or form fields. While these identifiers disclose direct system information, WordPress’ rich permissions and access control system prevent unauthorized requests.
A5 – Security Misconfiguration
The fifth item of OWASP states that:
“Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.”
According to WordPress, the majority of the WordPress security configuration operations are limited to a single authorized administrator. Default settings for WordPress are continually evaluated at the core team level. WordPress core team has also provided documentation and best practices that advises webmasters the common vulnerabilities and what they can do to keep WordPress installation secure.
A6 – Sensitive Data Exposure
The sixth item of OWASP is about properly protecting sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers steal or modify weakly protected data to conduct credit card fraud, identity theft, or other crimes.
WordPress user account passwords are salted and hashed based on the Portable PHP Password Hashing Framework. WordPress’ permission system is used to control access to private information such an registered users’ PII, commenters’ email addresses, privately published content, etc. In WordPress 3.7, a password strength meter was included in the core software providing additional information to users setting their passwords and hints on increasing strength. WordPress also has an optional configuration setting for requiring HTTPS.
A7 – Missing Function Level Access Control
OWASP stated that verification of function level access rights should not just be carried out at web applications level but also to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.
WordPress checks for proper authorization and permissions for any function level access requests prior to the action being executed. Access or visualization of administrative URLs, menus, and pages without proper authentication is tightly integrated with the authentication system to prevent access from unauthorized users.
A8 – Cross Site Request Forgery (CSRF)
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
WordPress uses cryptographic tokens, called nonces. Nonces are generated numbers used to verify origin and validate intent of action requests from authorized users to protect against potential CSRF threats. Each nonce can only be used once. These nonces are to WordPress provides an API for the generation of these tokens to create and verify unique and temporary tokens, and the token is limited to a specific user, a specific action, a specific object, and a specific time period, which can be added to forms and URLs as needed. Additionally, all nonces are invalidated upon logout. More details on nonces can be found in this documentation.
A9 – Using Components with Known Vulnerabilities
Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.
The WordPress core team closely monitors the few included libraries and frameworks WordPress integrates with for core functionality. In the past the core team has made contributions to several third-party components to make them more secure, such as the update to fix a cross-site vulnerability in TinyMCE in WordPress 3.5.2.
When necessary, the core team may decide to fork or replace critical external components, such as when the SWFUpload library was officially replaced by the Plupload in 3.5.2, and a secure fork of SWFUpload was made available by the security team for those plugins who continued to use SWFUpload in the short-term.
A10 – Unvalidated Redirects and Forwards
Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
In the article, WordPress assures that its internal access control and authentication system will protect against attempts to direct users to unwanted destinations or automatic redirects. This functionality is also made available to plugin developers via an API,
Conclusion – Is WordPress Secure?
Having studied in detail, comparing the advise by OWASP and how WordPress has documented, built in security processes and enabled security functions and APIs into its software core, I am convinced that Security in WordPress is taken very seriously, but as with any other system there are potential security issues that may arise if some basic security precautions aren’t taken. Let me quote from an article from WordPress:
“Fundamentally, security is not about perfectly secure systems. Such a thing might well be impractical, or impossible to find and/or maintain. What security is though is risk reduction, not risk elimination. It’s about employing all the appropriate controls available to you, within reason, that allow you to improve your overall posture reducing the odds of making yourself a target, subsequently getting hacked.”
From a blog by WPWhiteSecurity, the following quick statistics were provided:
- 41% of hacked WordPress were hacked through a security vulnerability on their hosting platform
- 29% were hacked via a security issue in the WordPress Theme they were using
- 22% were hacked via a security issue in the WordPress Plugins they were using
- 8% were hacked because they had a weak password.
The bulk of the hacking is not attributed to the WordPress software core but related to other contributing factors such as hosting platforms, themes, plugins and password management.
The research findings reported in Sucuri’s ‘WEBSITE HACKED TREND REPORT 2016-Q1’ states:
“Based on our data, the three CMS platforms most being affected are WordPress, Joomla! and Magento. This does not imply these platforms are more or less secure than others.
In most instances, the compromises analyzed had little, if anything, to do with the core of the CMS application itself, but more with improper deployment, configuration, and overall maintenance by the webmasters and their hosts.
I am convinced that Wordpress as a CMS is secured. The perception that WordPress has the most hacking attacks was simply a result of it being the most popular CMS with 60% market share, far above its next in line alternative (Joomla) which had only 6% market share. The problem does not lie in WordPress software core. The problem lies in many other aspects that may contribute to vulnerabilities of a website — e.g. hosting management, password management, themes and plugins version updates management.