Security is incredibly important for all the right reasons. However, a small blog or a 5-page business website is less prone to becoming a target as compared to a popular enterprise where competitors, top black hats, and other 3rd parties may have an incentive to receive some proprietary information which may be very, very expensive.
WordPress Security is also one of the 15 main obstacles that enterprises report in WordPress. I’ve discussed the list in a separate post based on our sales meetings and calls with various enterprises and what helped us sign several deals with multi-billion dollar brands.
Massive Distributed Attacks and Targeted Hacks
Generally, attacks are split into two main divisions:
- Automated mass attacks targeting hundreds of thousands or millions of websites
- Specialized attacks focused on a small number of websites (a few dozens) or even a single target
The first type is common among script kiddies looking for zero-day vulnerabilities in hacker forums or vulnerability databases. Often times, Perl or Python scripts are available and could be executed easily. Usually, hackers skip a step or two in order to avoid that, but even a fairly junior kid with some limited programming experience can figure it out with the right (or not) motivation.
The second type of targeted attacks is often more complicated and combines a set of activities that, when combined together, may lead to escalated privileges and unauthorized breach of data.
Technical and Social Engineering Attacks
I would also break them down into two separate components:
- Technical breaches
- Social engineering
According to two studies revealed by eSecurity Planet and SC Media state that 60% of enterprises were victims of social engineering attacks in 2016 and fully 84 percent of hackers leverage social engineering in cyber attacks.
Social engineering attacks are interesting as they depend on fooling people into giving some proprietary information somewhat voluntarily without going through the right security procedures or opening the wrong type of file or online resource leading to data leaks.
In other words, sending an email that seems legit to a general bank clerk who thinks that this comes from management may lead to an exploit even without going through all of the security hoops that most hacker movies show.
Social Engineering is Massively Effective
So, more often than not, social engineering is one of the key strategies that hackers use in order to link several activities that could lead to a successful breach.
Other than that – when talking about WordPress in particular – enterprise security and technical departments have to consider different aspects of the technical infrastructure that could be attacked separately.
In a .NET-driven technical stack (such as ASP.NET or any other Microsoft product), the underlying infrastructure usually includes a Windows Server, an MS SQL database, the .NET framework and so on.
WordPress, being a PHP-driven CMS, is written in PHP, runs on top of a MySQL database and is usually hosted on a Linux server running Apache or nginx.
With that in mind, a possible security breach can happen on multiple layers, such as:
- The Linux server itself
- PHP (mod_php or php-fpm)
- Other processes running on the server
- The network layer
- The WordPress Core CMS
- Installed WordPress themes
- Installed WordPress plugins
- All sorts of 3rd party applications and services
- The email server
- An FTP server
The list could go on depending on what’s hosted on the environment.
If we consider any PHP framework or a CMS, most of the points above would be valid. The difference with WordPress is the Core platform itself and the themes and plugins installed.
What Should an Enterprise Evaluate When Deploying WordPress?
So, an enterprise has to evaluate the code quality (security-wise) of the WordPress Core platform and decide on the right process of finding the balance between building everything else from scratch and cherry-picking plugins that have been reviewed for possible security breaches.
There have been various security leaks in the WordPress Core platform but, globally speaking, they have been fairly limited and the number hasn’t been extremely concerning. Being open source, thousands of contributors and various security teams spend a lot of time trying to break the platform and disclosing responsibly vulnerabilities as they are found.
The WordPress Core team has been open and assertive and implements the right patches straight away. The fact that automatic minor Core updates have been around for several years now helps tens of millions of websites that receive updates within a day or two of releasing a minor security fix.
There are tens of thousands of WordPress plugins online and finding some that are proven to be safe isn’t trivial. Which is why many enterprises spend a lot of time on reviewing trustworthy plugins and deploying on approval and reviewing each update separately before deploying to production.
Other business-driven solutions are developed from scratch and coordinated with security teams as well.
Top 3 Enterprise Considerations for WordPress
Enterprises have three main things to keep into account:
- Their brands are often quite popular so they are more lucrative for hackers and receive a larger volume of hacking attempts on a monthly basis
- Their infrastructure is usually far more complex than a yet another blog or a small magazine (more feature-rich which means more custom code on top of the Core platform)
- They employ thousands or tens of thousands of employees and the odds of someone in-house leaking data by mistake is much higher
With the right security policies in place and responsible and regular code reviews in-house, using WordPress for enterprises is a great choice as seen with dozens of established enterprises.
Use Case: Powering a Bank Website With WordPress
Okay, most of the answers here are inherently incorrect or incomplete for various reasons. Let’s tackle that with some research data and brainstorming into account.
1. What is a Bank’s Website?
First off, “powering a bank’s website” is quite vague. We’ve been building WordPress solutions for 3 different banks over the past 5 years. The three platforms in particular were:
- An informational portal for bank A mainly suited for company news, listing the branches of the bank, all sorts of corporate information. We’ve also built a financial calculator for credits – a complex system that replicates the software application processing amounts, interest over time, and some machine learning algorithms for assessing risk.
- A payment gateway platform for 3rd party vendors, including the WordPress extension as well. That was a separate (yet branded and maintained by the bank) website for integrations.
- A set of security modules and privacy plugins and tools for another bank integrated with a reporting platform. Aggregating credit card statements and all sorts of user-driven details related to one’s payment status. Monetary and sensitive data information was indeed provided, although payment processing wasn’t active on the system (sending transfers across other accounts).
Two out of the three applications weren’t remotely related to the main payment system that the banks used for e-banking. The third one was the closest, being thoroughly audited by Verizon’s Internal Network Penetration Testing squad and a few more high-profile white hacking organizations (passed successfully).
As a conclusion, not every bank’s website is dealing with payments or any sensitive data.
2. Bank Security Vulnerabilities Report
A study by SC Magazine from November 2013 highlights top site attacks on world’s biggest banks:
A Swiss penetration testing firm, High-Tech Bridge, analyzed publicly reported incidents affecting major websites for banks, and found that, over the last 10 years, cross-site scripting (XSS) vulnerabilities accounted for 80 percent of security incidents.
A common XSS attack method might involve a hacker using code injections to steal visitors’ data, like cookies, or manipulating what victims see to trick them into inputting sensitive personal or financial information.
In the experiment, High-Tech Bridge used a list of the world’s 50 “biggest banks” in 2012 (as determined by Global Finance magazine) and dug up public attack reports posted on security and hacking sites or online archives for XSS attacks and site defacements.
Financial institutions on the list included Bank of America, HSBC, Barclays, JPMorgan Chase, Wells Fargo, Bank of Montreal, and number of other major banks throughout the globe.
Out of 102 reported incidents, that occurred between 2003 to present, High-Tech Bridge found that Bank of America had the most public reports of security issues affecting its site.
As a conclusion, we can outline two separate notes:
- It does appear that non-WordPress websites are just as susceptible to web attacks as a WordPress-driven one (if not more)
- 80% of all security incidents are XSS-driven
The official WordPress security whitepaper showcases attention to OWASP’s list and major industry vulnerability categories when it comes to reviewing the existing code base and introducing new ongoing features in the WordPress Core.
XSS has a special place in the document with some practical examples of what the WordPress Security Team (and other independent security consultants) look for with regards to XSS:
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.
The Open Source nature of the project supports those needs, given the tens of thousands of contributors, researchers, and developers who use WordPress for tens of millions of projects – in different applications – being able to replicate a problem in different context, thus easily and quickly identifying potential issues.
When compared to closed source and corporate system, I’ll remind the BadTunnel vulnerability discovered in 2016 which “could give attackers a way to set up man-in-the-middle attacks against victims by getting them to click on a link, open a Microsoft Office document or plug in a USB drive” and “can expose you to attackers who aren’t on your network, and your firewalls won’t save you”. For the record, this vulnerability affected all versions of Windows from 95 to 10, or about 20 years of vulnerable production system running in enterprises and corporate intranets with remote access exploitable by black hats.
There goes the “closed source” theory – at least to some extent.
Another study from 2016 covers some data regarding where banks are most vulnerable to cyber attacks now:
That said, let’s investigate what makes web applications most vulnerable to attacks?
Banks are getting hit hardest in their web applications. Forty-eight percent of bank data security incidents in 2015 involved compromised web applications, the Verizon report found.
Some apps are compromised through code injections. GozNym malware, for instance, typically inserts code into banks’ websites that creates pop-up screens asking for personal information. Through SQL injection, malware can access sensitive information in databases or gain access to other parts of a network through a web app.
Web app attacks are hard to detect since banks have thousands, sometimes millions of legitimate users accessing their sites. Finding the bad behavior in the noise is difficult, especially if the cybercriminals use multiple proxy servers and space their attacks over minutes or days.
The best defense? Two-factor authentication, Novak said. “We still see a lot of financial institutions using single-factor username and password,” he said. According to the report, 63% of confirmed data breaches in 2015 involved weak, default or stolen passwords.
As Matt Mullenweg (co-founder of WordPress) said himself in a Quora answer, running up-to-date software and using strong passwords are absolutely critical. Moreover, 2-factor authentication was mentioned in his reply as well, including a number of different systems including Jetpack’s 2FA component which has been thoroughly tested on WordPress.com as well – the 7th top ranking website in the US now, among giants like Google, Amazon, Facebook, eBay, or Wikipedia.
3. What Makes a WordPress Site Vulnerable?
A common misconception is that WordPress is inherently insecure. While there are regular vulnerabilities discovered and immediately fixed in core, their number, regularity, and impact is significantly lower (given its exposure) than almost any other web platform out there.
The four main reasons WordPress websites are being hacked are:
- Outdated WordPress Core and corresponding themes/plugins
- Insecure themes or plugins (voluntarily installed by website owners)
- Inherently insecure hosting (which is platform-independent as malicious users can gain access to any online software running on a generic host)
- Poor passwords, logging from an open Wi-Fi network or another user-driven mistake unrelated to tech
There are almost no grounds as to why WordPress is inherently insecure for a bank’s website. Granted, processing payment transactions through a WordPress platform may not be ideal. Many transactional platforms are not even built on top of a web platform, and run in C++, Java or another language that supports multithreading, introduces several security layers in-between, and passes data to a web application used for interactivity with the end user.
While there are vulnerabilities that can be pointed out in the WordPress Core which may, indeed, be exploited in an outdated system, there has been no thorough and extensive research comparing a WordPress Core build with another web application framework or platform. Relying on public information from media outlets regarding small business owners running an outdated site on a $3/mo web host with 60+ random plugins is not a comprehensive report for the stability of the WordPress platform running in a secure context itself.
As a conclusion, WordPress may not be the standard solution for a banking website (for other reasons such as the underlying database layer or the standard components provided by the Core in certain instances), but there is no objective reason that it should be ruled out in all cases. There are several success stories showcasing WordPress websites ran by popular banks and customers should rest assured that the sensitive information is kept safe and ran on intranets that provide limited access to public-faced websites.