7 Steps to Secure a WordPress Site
Many companies operate under the assumption that their WordPress sites are secure -- and that couldn't be anything further from the truth.
WordPress sites account for more than one-third of all websites on the Internet, including some of the most highly trafficked sites and numerous e-commerce sites. So it stands to reason that companies would spend a lot of time and resources on protecting site security, right?
Unfortunately, says Ted Harrington, executive partner at Independent Security Evaluators (ISE), too many organizations believe that because WordPress runs on open source, it's innately secure.
"The assumptions many people have is that because it's open source, the best ethical hackers will work to find security vulnerabilities and we don't need to focus on security," Harrington says. "The truth is we still need defense in-depth and can't assume that WordPress is secure."
Indeed, over the past year, critical vulnerabilities were discovered that impacted more than 1.5 million WordPress sites and were often linked to one of the 50,000-plus plug-ins that enhance WordPress functionality, adds Timothy Chiu, vice president of marketing at K2 Cyber Security.
"Security vulnerabilities continue to be discovered," says Chiu. "Each new vulnerability is a good reminder that plug-ins can affect your site's overall security."
Armed with the seven tips that follow, WordPress administrators and security teams will have the basics they need to lock down their sites. Read on.
Few companies step back and think about what they really need to protect, says ISE's Harrington. Start by developing a threat model (plan) for your WordPress site. What data does the company need to protect? Which adversaries are they protecting against? For example, are they posting information or intellectual property that would interest a nation-state? Which attack surfaces do they need to protect?
"Think of it in football terms," Harrington says. "This weekend Tampa Bay plays Green Bay. They wouldn't go into the game without evaluating the opposition and analyzing what they need to do to beat this specific adversary. The same holds true in security."
According to Ponemon Institute research, 60% of breaches are linked to a vulnerability where a patch was available but not applied. WordPress administrators need to regularly update the operating system, Web server, and WordPress itself, K2 Cyber Security's Chiu advises.
"Companies should always run the latest version of WordPress and any of the plug-ins they run," he says. "Administrators should also look over all the plug-ins running on the site and delete the plug-ins you're not using. They are only vectors for bad actors to launch attacks."
WordPress plug-ins are typically written in PHP, a language particularly vulnerable to the OWASP Top 10 ranking of Web application security risks, says K2 Cyber Security's Chiu. Organizations need to take application security more seriously, he says, starting with protection for well-known problems.
Many of the critical vulnerabilities that have been identified in WordPress are well-understood, such as cross-site scripting (XSS) and remote code execution (RCE), Chiu adds. Security researchers consider RCE one of the most dangerous vulnerabilities because it gives the attacker the ability to run almost any code on a hacked site. Some of the largest past data breaches, like the Equifax attack, started with an RCE attack, Chiu says. And XSS, which stands at No. 7 on the OWASP Top 10, has been on the list since its creation.
Revised last September, NIST SP 800-53 includes two major updates that offer insights into how security pros can implement app security, including on WordPress sites, says K2 Cyber Security's Chiu. The new framework includes requirements for runtime application self-protection (RASP) and interactive application security testing (IAST).
Unlike perimeter security solutions such as Web application firewalls (WAFs), RASP solutions sit on the same server as the application and deliver continuous security for the application during runtime to protect vulnerabilities in the application from being exploited. By residing on the server, Chiu says, RASP solutions offer visibility into the application, analyze the application's execution for better validation, and understand the context of the application's interactions.
With the recent update to require IAST, application security gets a new focus in development as part of the mainstream NIST framework and should help developers catch security flaws before an application launches, Chiu adds. While NIST frameworks are requirements for federal agencies and the organizations that work with them, the new requirements around RASP and IAST should encourage all kinds of companies to take a fresh look at their application security and the tools they use in their own infrastructure, including WordPress sites, he adds.
Companies don't always have a systematic way to manage their WordPress sites, says ISE's Harrington, who outlines such a strategy in Hackable: How to Do Application Security Right. For those who are just posting a blog and basic information, they may not need to go beyond his first three steps: perform a design analysis, run a scan, and check for known vulnerabilities. But even companies that are doing e-commerce and high-end video apps on their site need to go through this process.
All organizations need to understand how the site should work. First, Harrington maps out, learn the fundamentals of the app through a design analysis: the features, how users navigate through it, how access will get provisioned and where users can input values. Why does the site exist? What business problems does it solve? What data need protecting?
Second, Harrington says companies should scan their sites. Scans are efficient, inexpensive, and offer information that helps in later assessment stages. Most attackers run scans first, so it's smart to do the same in order to see what the hackers see. Still, remember that scanning doesn't represent a comprehensive effort to find security vulnerabilities. It's just one piece of an overall strategy.
Finally, test for known vulnerabilities by checking for common security issues. Examples include cross-site scripting (XSS), which lets attackers inject malicious scripts into web pages viewed by other users; cross-site request forgery (CSRF), in which a third-party web page can trick a user's browser into sending unauthorized commands to a Web application; broken authentication, a failure to verify user identity; and broken access control, a failure to enforce user permissions. If the company doesn't have the expertise to run these processes in-house, a third-party security expert can run these processes instead.
Here's the meat of the analysis for organizations that depend on their WordPress sites for e-commerce and higher-level video functions: By abusing functionality, ISE's Harrington says he means using the functionality of an app in an attack against itself. For example, if the user name field expects up to 20 characters, input something like 2,000. Or if the input field expects alphanumeric characters, input a command and see how the system responds when it's attacked. Look for the unexpected: The system is intended to do X, but what if we try to make it do Y instead?
Next, understand how chain exploits work. Think of them as two vulnerabilities that in and of themselves are benign but when combined together can cause security issues, Harrington says. One example: predicting account IDs and resetting credentials with an account ID. Separately, they can't do much damage, but linked together they can let hackers have unfettered access to the network and potentially overload a business process to crash the system.
Security teams also need to understand how different vulnerabilities might be combined and then mitigate them to minimize exploitability. For example, understanding how the predictable account IDs and broken authorization works (ability to reset passwords with just the account ID) points to what to do about it: Randomize the IDs and require more than just the account ID to change credentials. In doing so, the exploit becomes neutralized.
Finally, security teams have to look for unknown unknowns -- issues they may not have considered. Unfortunately, this last phase often gets overlooked because so much is involved, but it's the most important and where a company should place the lion's share of its effort. Turning to help outside the organization could be helpful to find these issues. Furthermore, implement defense in-depth in to mitigate issues that might surface in the supply chain.
Here's the meat of the analysis for organizations that depend on their WordPress sites for e-commerce and higher-level video functions: By abusing functionality, ISE's Harrington says he means using the functionality of an app in an attack against itself. For example, if the user name field expects up to 20 characters, input something like 2,000. Or if the input field expects alphanumeric characters, input a command and see how the system responds when it's attacked. Look for the unexpected: The system is intended to do X, but what if we try to make it do Y instead?
Next, understand how chain exploits work. Think of them as two vulnerabilities that in and of themselves are benign but when combined together can cause security issues, Harrington says. One example: predicting account IDs and resetting credentials with an account ID. Separately, they can't do much damage, but linked together they can let hackers have unfettered access to the network and potentially overload a business process to crash the system.
Security teams also need to understand how different vulnerabilities might be combined and then mitigate them to minimize exploitability. For example, understanding how the predictable account IDs and broken authorization works (ability to reset passwords with just the account ID) points to what to do about it: Randomize the IDs and require more than just the account ID to change credentials. In doing so, the exploit becomes neutralized.
Finally, security teams have to look for unknown unknowns -- issues they may not have considered. Unfortunately, this last phase often gets overlooked because so much is involved, but it's the most important and where a company should place the lion's share of its effort. Turning to help outside the organization could be helpful to find these issues. Furthermore, implement defense in-depth in to mitigate issues that might surface in the supply chain.
WordPress sites account for more than one-third of all websites on the Internet, including some of the most highly trafficked sites and numerous e-commerce sites. So it stands to reason that companies would spend a lot of time and resources on protecting site security, right?
Unfortunately, says Ted Harrington, executive partner at Independent Security Evaluators (ISE), too many organizations believe that because WordPress runs on open source, it's innately secure.
"The assumptions many people have is that because it's open source, the best ethical hackers will work to find security vulnerabilities and we don't need to focus on security," Harrington says. "The truth is we still need defense in-depth and can't assume that WordPress is secure."
Indeed, over the past year, critical vulnerabilities were discovered that impacted more than 1.5 million WordPress sites and were often linked to one of the 50,000-plus plug-ins that enhance WordPress functionality, adds Timothy Chiu, vice president of marketing at K2 Cyber Security.
"Security vulnerabilities continue to be discovered," says Chiu. "Each new vulnerability is a good reminder that plug-ins can affect your site's overall security."
Armed with the seven tips that follow, WordPress administrators and security teams will have the basics they need to lock down their sites. Read on.
About the Author(s)
You May Also Like
CISO Perspectives: How to make AI an Accelerator, Not a Blocker
August 20, 2024Securing Your Cloud Assets
August 27, 2024