Are WordPress Plugins safe to use?

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. 

Plugin-based Web Development

Generally speaking, WordPress is the most popular Content Management System (CMS) in the world as it powers more than 30% of the Web.

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.

Third-Party Development

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.

No Security Guidelines

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?

Is WordPress Really Secure?

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.

Read More: 11 Effective ways to Scale up Your WordPress Website for High Traffic

Where do these Vulnerabilities come from?

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.

What are Plugins?

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.

Implications of Plugin Development

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.

What are the Consequences of Compromised Plugins?

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.

Security Vulnerabilities

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.

WordPress Complexity

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.

Examples of Plugin Vulnerabilities

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:

• Data Processing Errors
• Improper Input Validation
• Information Exposure
• Path Traversal
• Security Features
• Access Controls
• Improper Access Control
• Improper Authorization
• Improper Authentication
• Cross-Site Request Forgery
• Unrestricted Upload of File
• Files Accessible to External Parties
• Link Following
• Open Redirect
• Command Injection
• OS Command Injection
• Cross-site Scripting
• SQL Injection
• Code Injection

For more context, let’s explore the most common attack and vulnerabilities.

• SQL Injection: SQL injections typically happen when an attacker gains access to a user’s WordPress database and all of their website’s data. SQL injections can also be used to insert new data into a database, including links to malicious or spam websites.

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.

• Cross-Site Scripting: This attack allows the running of a script on the client in order to bypass access controls. It typically targets all visitors to a site. In a hosted environment, such an attack can be used to steal the session cookies of the site admin, allowing the attacker to pose as the admin.

• Cross-Site Request Forgery: This vulnerability allows the hacker to perform an application-level transaction on behalf of the victim. In a hosted environment, an attacker can log onto the site on the admin’s behalf and perform malicious activities such as re-directing users or performing admin transactions.

Common in WordPress plugins, Cross-site scripting vulnerabilities work in a manner like this – an attacker finds a way to get a victim to load web pages with insecure JavaScript scripts.

Where do most vulnerabilities appear?

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 PHP Code Writing Process

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

Are Vulnerabilities caused by WordPress Plugins critical?

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.

How long can a vulnerability survive in a WordPress plugin’s code?

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.

Possible Mitigations and Detection Methods

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:

1. Understand how data is used and the encoding expected by the core parts of WordPress. In this instance, developers should always assume all input is malicious and reject any input that does not strictly conform to the required encoding pattern, or transform it into a valid input.
2.  To protect databases from SQL Injection, developers should use parameterized SQL statements by separating code from data manipulation. Also, always check the headers to verify whether the request is from the same origin. Furthermore, it might also be useful to avoid exposing data to unauthenticated attackers.
3.  A good practice is avoiding the GET method for any request that triggers a state change.

Vulnerability Detection

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.

Best Practices to Protect your WordPress Application

• Download plugins only from reputable sources such as WordPress.org: As anyone can develop a WordPress plugin, hackers notoriously exploit this vulnerability to hide their own malicious plugins. A reputable marketplace might not fully guarantee access to harmless plugins, but is recommended as a mitigating practice.
• Always ensure that all your plugins are up to date: WordPress users typically get notification emails which they often ignore. Be sure to set your plugins to automatically update, or at least manually upgrade them yourself.
• Verify the security posture of the plugin by scanning it for security issues:  Most plugins are open-source, which means that their source code is available. So, be sure to use a static source code analysis tool which will provide you with the plugin’s “bill of health”. Some advanced scanners can even point you to the optimal and quickest fix recommendations.
• Remove all unused plugins: Unfortunately, the code of old, unused plugins typically remains on the server – even when the plugins are inactive. So, be sure to always remove unused plugins as part of your WordPress site maintenance

Recommendations for Plugin Developers

• Always incorporate security during plugin development: Vulnerabilities incur a higher cost to fix later, so, always integrate security within the plugin development as part of your secure Software Development Life Cycle (SDLC) process.
• Run the plugin through a code scanner to ensure that it stands up to the latest security standards. Ensure conduct a comprehensive source code analysis test during development and before release.

Developing Secure Plugins

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.

Final Thoughts

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.

---