11 Effective ways to Scale up Your WordPress Website for High Traffic
8th February 202015 mins
Over the years, research has identified that more than 20% of the 50 most popular WordPress plugins are vulnerable to common Web attacks. Furthermore, targeted research into e-commerce plugins discovered that 7 out of the 10 most popular e-commerce plugins contain vulnerabilities.
Unfortunately, hackers typically exploit these vulnerable applications to access sensitive information such as health records and financial details. In other cases, vulnerabilities allow hackers to deface sites or redirect them to other attacker-controlled sites.
In more recent instances, we have seen malicious WordPress plugins being utilized not just to maintain access on compromised servers, but also to mine for cryptocurrency. So, this poses the question of how safe are WordPress plugins.
In this blog, we’ll deeply focus on WordPress Plugins as potential sources of security breaches.
That said, the core strength of WordPress lies in its ability to allow customization of sites through its extensive offering of tens of thousands of plugins and themes. These plugins vary in type and functionality- from adding a contact form to the site to optimizing a blog for SEO, or even publishing new posts to Facebook automatically.
The primary idea behind plugin-based development is to offer additional features to extend the core capabilities of a system. Essentially, the core of the application is typically maintained by a set of long-term developers while third parties build a number of plugins around the core of the application
This process is beneficial for both the application provider and the plugin provider as the application provider can focus more on the core functionality while the plugin provider doesn’t have to be concerned about the plugin’s infrastructure, which is provided by the application’s core functionality. Generally, WordPress is also supported by a global community of thousands of commercial and open-source software developers and enthusiasts.
Overall, though some set of coding standards and recommendations exist, there are technically no security guidelines or standard requirements that a plugin developer needs to strictly adhere to. This means that a vulnerability in one plugin can propagate across millions of websites.
And since WordPress is extensively used, it’s consequently a popular target for attacks. So, in essence, a hacker exploiting a plugin’s vulnerability can infect thousands of sites. A scenario that has already been witnessed by many bloggers.
Unfortunately, plugin-related vulnerabilities also tend to be recurrent, exploitable, and hard to detect. Therefore, there is a need to further understand such vulnerabilities to mitigate any relevant security threats. Let’s dig deeper, shall we?
First things first, let’s answer this question. For the most part, WordPress as a raw ecosystem is very secure as long as WordPress security best practices are adhered to. On average, about 30,000 new websites are hacked each day on the web. These hackers tend to target WordPress websites because of plugin vulnerabilities, weak passwords, and obsolete software. So, attaining the best security requires a level of intentionality, which means following a few basic WordPress security best practices to reduce your vulnerability to attack.
A recent report by wpscan.org revealed that WordPress has nearly 4,000 known security vulnerabilities. A large majority of these vulnerabilities were caused by plugins. And while some of these plugin-related vulnerabilities may have severe consequences, many remain unnoticed for years before being fixed. In most instances, they can commonly be fixed with small and localized changes to their source code.
However, before we get ahead of ourselves, let’s take a step back.
Basically, plugins are software extensions that complement applications with new custom-tailored functionality and behavior. In particular, WordPress offers thousands of plugins (more than 52,000), which have been used to build thousands of customized web applications.
Since plugin-based web applications went more mainstream, more developers turned their attention to exploring their potential to reimagine web applications by composing, configuring, and extending different plugins with cutting-edge functionality.
That being said, the ability to exploit plugins to extend web systems with additional and custom functionality has both positive and negative implications for developers. Firstly, on a positive note, there are normally multiple customization options from which to choose, giving developers the ability to quickly and easily build web applications that are custom-tailored to the users’ needs. Thus, facilitating rapid prototyping and development.
However, on the negative side, a web application can end up being a complex composition of multiple plugins from different sources. Which ultimately poses concerns related to plugin security. For instance, TimThumb, a plugin that was employed by millions of WordPress-based applications was reportedly open to an exploit where attackers could deliberately execute remote code.
As a matter of fact, roughly 15% of the vulnerabilities in web systems can be regarded as critical according to the United States National Vulnerability Database (NVD), with almost 35% of them being easily exploitable vulnerabilities.
Aside from users losing financial information or even having their health records compromised, the more severe a vulnerability, the greater the financial impact on software companies. Additionally, this is further exacerbated if developers fail to release a viable path at the time of disclosure. Thus, plugin vendors typically strive to create more secure applications
Let’s now investigate some security vulnerabilities typically found in plugins to get a broader understanding of their consequences and implications.
As we have gathered, vulnerabilities open up opportunities for the potential misuse of software systems. Ultimately, since WordPress allows millions of developers across the world to create their own plugins, it is unrealistic not to expect a level of compromise to occur in plugins.
Resultantly, security can be violated by unanticipated plugin interactions with the core system, leading to vulnerabilities that can be potentially exploited by attackers. This then implies that the security of web systems hinges on keeping both the core system and plugin vulnerabilities in check.
Because of WordPress’s complexity, it sometimes tends to be plagued by vulnerabilities. For instance, WordPress provides an intuitive infrastructure to which plugins can contribute new features by modifying shared global states or running a function at a specific point in the execution of the system core. Consequently, a plugin vulnerability can crop up when the plugin sends malicious input data to core components without proper sanitization or input validation.
Ultimately, the most common plugin vulnerabilities are cross-site scripting, SQL Injection, and Cross-site Request Forgery. Overall, the most dangerous vulnerability type which can be easily exploited by attackers is SQL Injection. However, other vulnerabilities, sources of breach and compromises do exist, namely:
For more context, let’s explore the most common attack and vulnerabilities.
SQL injections allow the execution of commands on the back-end server, such as the extraction of sensitive information. In a hosted environment, a SQL Injection attack can further be used as a stepping stone for attacks against non-vulnerable sites.
A technical study discovered that most vulnerabilities (about 92%) appear in plugin code. Furthermore, according to the results, vulnerabilities such as Cross-site Scripting and Cross-site Request Forgery were more common in plugin code, while other vulnerabilities were more prevalent in core code. Relatedly, the study revealed that the quality of plugins varied and that there was no correlation between the ratings of plugins and the number of vulnerabilities found in them.
The code-writing process could be the genesis of any vulnerability or compromise. Generally speaking, PHP is well-known for supporting the execution of arbitrary code on the server side without directly invoking the host operating system. That said, whenever developers are negligent during the code-writing process, it raises the possibility of the introduction of Cross-site Scripting vulnerabilities into plugin code.
On the other hand, regarding SQL Injection is a common vulnerability because it can easily be detected and exploited. Ironically, even a website with a small user base is likely to be subject to an attempted attack of SQL Injection.
Some of the exposure to vulnerabilities stems from developers using unsafe resources. Similarly, proper input validation is still a major challenge for plugin developers because many of the recently developed plugins have been created by not-so-skilled developers
All things considered; a vulnerability may negatively influence the web system in several ways. For example, the successful exploitation of a vulnerability can lead to a complete loss of confidentiality, though without loss of availability.
As has been noted, SQL Injection seems to be the most dangerous vulnerability type, though it only partially affects the integrity, availability, and confidentially of the system. However, such a vulnerability has the potential to allow attackers unrestricted access to files or information.
So, inadvertently, the majority of the vulnerabilities have to potential to lead to data breaches while a few vulnerabilities do not necessarily expose web applications to serious security risks. Either, it’s important to avoid taking chances with such odds.
Ordinarily, vulnerabilities in code tend to transit through distinct states, variating from the introduction, passing by the disclosure, until the release of a patch fixing the security threat.
Typically, a vulnerability is disclosed when the discoverer reveals the details of the security threat to a wider audience. Eventually, the vulnerability is fixed when the developer releases a patch that corrects the underlying security threat. However, sometimes a vulnerability remains unnoticed in a web application for years before being identified and then fixed.
Prevention is better than cure as most people say. So, if plugin developers can fully understand, detect, and eliminate Cross-site Scripting, SQL Injection, and Cross-site Request Forgery, it’s possible that we’ll have plugins with 75% fewer vulnerabilities.
However, it is worth noting that these three vulnerabilities are not the only vulnerabilities that can be exploited by attackers. But rather, are the most common vulnerabilities.
So, while these proposed mitigation strategies do not guarantee that a given plugin will be fully secure, they, however, set good principles for vulnerability prevention. For example:
Unfortunately, there is no consistent method to detect the most common code weaknesses with 100% of accuracy and coverage. Unfortunately, even modern techniques that use data flow analysis to detect Cross-site Scripting, sometimes give false positives.
In contrast, manual analysis methods such as code reviews tend to be more effective than fully automated methods, especially for vulnerabilities related to design. As an example, Cross-site Request Forgery is especially hard to detect reliably using automated methods because each application has its own security policy and manner to indicate which requests require strong confidence that the user intends to make the request.
However, on the other hand, manual analysis can be useful for finding SQL Injection, though it might not achieve the desired code coverage within limited time constraints. This can become difficult for weaknesses that must be considered for all inputs since the attack surface can be overly large.
Consequently, some organizations stress the importance of a balanced approach that includes both manual reviews and automated analysis that encompasses all phases of the web system development process.
As has been noted, plugin developers need to strive to write secure code. Unfortunately, many developers still do not know how to, as they are not so skilled. Particularly, given the nature of the most common vulnerabilities cited above, it’s clear that many developers do not understand common attacks, the security functions provided by the language and platform they use, and how to use applicable practices to mitigate security problems.
Hence, our recommendation at Creole Studios is that maybe new methodologies should be developed tailored to plugin developers. Such methodologies should promote security in the requirements and design phases as developers are the most important entities in software security.
To summarize the topic, WordPress Plugins can be compromised, with the most common vulnerabilities being Cross-site Scripting, SQL Injection, and Cross-site Request Forgery.
Unfortunately, research seems to suggest that the frequency with which these vulnerabilities occur does not seem to be declining with time. It is safe to assume that the main reason for this is that most WordPress Plugin Developers remain somewhat under-skilled in regard to secure programming.
That being said, the first line of defense should be the development team! And we believe that once the best security practices are effectuated, then users can sleep better at night, knowing they are protected from cyber-criminals.
For more information on our WordPress security practices, be sure to kindly reach out for a consultation.