What Happens When a Blog Engine Tries to Put on Big-Boy Pants
For me and my team at nvisionative we have never been tied to any one CMS. I have always said, our business does not rely on DNN. I realize this may come as a surprise to some of you in the DNN community, but it’s true. Rather than forcing everyone into one toolset, we focus on building solid solutions for our clients. To do that, we keep an open mind and use the right tool for the job. That said, when it makes sense, we do in fact choose DNN. However, there are times when we don’t have a choice in the matter and we are forced to use tools that are mandated by our client or are inherited from an existing client implementation. Lo and behold, sometimes (more times than we’d like to admit) those tools include WordPress.
For those that do not know, WordPress was built initially as a personal publishing system (blog) and was actually built on top of, and as an official successor to, b2/cafelog. Its technical stack of choice was PHP and MySQL, sporting a General Public License (GPL), which made it quite attractive to the masses. It has gained tremendous popularity over the years and has grown into more of a Content Management System (CMS), though that is still debated by many whether or not it deserves a “CMS” designation. Nonetheless, according to W3Techs, WordPress powers 60% of all websites where they know the CMS and 30.9% of all websites.
If you talk to nearly anyone in the WordPress Camp, they will tell you, “it’s easy, it’s free, and there is a plug-in for anything you want to do! So why not use it?”
What they won’t tell you is what, perhaps, they don’t know. Herein lies the scary part and exactly why we are VERY CAREFUL when dealing with WordPress implementations.
The intent of this blog is not to be an extensive list of all things to be careful about (because that list is quite extensive). However, we realize many of you in the DNN community may have heard of, or even used, the whole security argument when evaluating DNN versus WordPress. Are we just to accept the argument though and leave it to generalizations when making a case to clients or ourselves? Trust it blindly? I believe not! Therefore, I will expose just one security vulnerability that alone should be enough to help you make an educated decision.
In recent versions of WordPress, there is a REST API. On the surface, this a really great thing! It allows you to improve the overall user experience by building fast client-side features via plugins that can make API calls for access to server-side data without having to rely on slower PHP hooks for that server-side data access.
You can also use the REST API to integrate third-party apps (e.g., other web apps, mobile apps) to access data such as posts, categories, tags, media and much more. Some API actions require authentication. For example, creating, updating or deleting a post. Cookie authentication is the only authentication mechanism available natively in WordPress, but there are plugins that may be added to provide other authentication methods such as OAuth and JSON Web Tokens (JWT). An authentication plugin is required for authenticated requests from outside of the WordPress admin, themes, or plugins.
Most of the GET (read-only) requests though are possible anonymously. This makes accessing most data extremely easy. So, if you just want to see the data, you don’t even have to write a single line of code!
The WordPress REST API uses a format like the following for their endpoints (URL methods that perform a specific function):
These endpoints are intended for use within the context of code. However, to see the response information for an endpoint without writing a single line of code, you can access the URL in any modern web browser and in return view a JSON response. So, ready for the really scary part?
The Scary Details
First, let me say, not all WordPress sites will apply. It depends on the specific version of WordPress and whether or not any measures have been taken to address this vulnerability, either by custom code, plug-in or built-in hosting provider mechanisms. That said, an out-of-box implementation of WordPress 4.7 will expose a list of all USERS via anonymous access, including each user’s name, username, Gravatar link and other associated meta data! Following is an example from a prominent tech news site. For security reasons I have obfuscated any sensitive data.
This information can be exposed to and enumerated by both humans and BOTs to harvest sensitive information. With this information in hand, brute-force attacks can be made against the website to gain unauthorized access. And people wonder why so many WordPress sites get hacked?
What does the WordPress REST API Team have to say about this? Well, hold on to your butts…here it goes…
"Usernames are already exposed through themes, RSS feeds, etc, and we do not consider them a security issue. You can install a third-party plugin if you would like to limit access to this data."
We all know DNN (DotNetNuke) has not been unscathed over the years from security vulnerabilities. However, being in the community since Day 1, I can still count the number of substantial security vulnerabilities on just one hand. That is saying something! And even during those times, the vulnerabilities were addressed in a timely and sensitive manner, and, weren’t as serious and as blatantly obvious as this WordPress vulnerability (which is STILL in their documentation as of the date of the writing of this blog).
If this level of security vulnerability (as a feature nonetheless) can be released like this, you must put into question EVERY update over time and especially in the future. Now that stronger regulations are being imposed, like GDPR, your business as a whole is more vulnerable than ever. I know some CMS consultants that go as far to tell clients they won't even touch WordPress sites due to the level of risk it puts on their own companies.
The Saving Grace
For a moment, let's assume you have one or more WordPress sites, are reading this blog, and are now concerned about what to do. You have invested a great deal into making your WordPress site great, but now you are worried about it being vulnerable. The bad news is you probably should be worried. The good news is we can help you either get onto a more secure CMS (like DNN) or, worst case scenario, help secure your WordPress site(s).
The Bottom Line
I hope having a concrete example helps you make solid decisions for yourself, your company, and your clients. Out with liability-first and in with security-first!
blog comments powered by