Mitigating Known Security Vulnerabilities

Every software product on the planet seems to have security vulnerabilities. Barebones CMS is no exception. In fact, several security vulnerabilities were specifically programmed into Barebones CMS. This is probably the only product in existence with intentional, known security vulnerabilities built into it from version 1.0 with no plans to ever fix them.

Obviously, this document is absolutely essential to fully locking down a Barebones CMS installation to keep out the bad guys. Reading this carefully will likely save your website from getting hacked. Vulnerabilities are ordered from most severe to least severe.

The Preview Frame

The preview area in the main CMS editor is actually a security vulnerability. It is possible to write Javascript with a Web Designer account that elevates the privileges of that account to a Developer account the moment a Developer views that page inside the browser or simply creates a new privilege enhanced account. It is also possible to do the same thing as a user without any account at all with an improperly written widget that somehow runs Javascript that users somehow submit.

Barebones CMS assumes that the people working together are trustworthy. It also assumes that HTML is security-clean. This security vulnerability is caused by HTML itself!

Security done right is to have a default policy of deny-all access and then only allow access as needed. HTML/Javascript is a fixed deny-some, allow-some policy (unchangeable by the HTML/Javascript developer) that assumes that all code in the same domain is trusted but all code on other domains, and even on subdomains, is untrusted. The truth is that we can't always trust code even in the same domain but HTML/Javascript assumes that it is okay to do so and outright denies completely trusted domains and subdomains. This immediately creates an inherent security vulnerability within HTML/Javascript and is the root cause of most web-based cross-site security vulnerabilities that are found and is the source of frustration of all the HTML/Javascript cross-domain scripting issues that every web developer experiences.

As incredulous as it sounds, HTML itself is the security vulnerability, not Barebones CMS! If you want to see this security vulnerability fixed, yell really loud at the W3C Standards body.

Until this security vulnerability is fixed at the Standards-level, there is no way to deal with it other than to be really, super-careful (vetting programmers writing Widgets and Shortcodes that get uploaded) and only use Barebones CMS in environments where you trust the people working with you.

Packet Sniffing

When Barebones CMS is installed, it recommends both installing and running the main CMS through SSL only. Failure to do so opens up the CMS to packet sniffing and replay attacks. This issue is true of any CMS run over HTTP instead of HTTPS.

It is highly recommended that all interactions with the editor be done over SSL. This is especially true when planning to use the editor on public networks (e.g. Wi-Fi).

Also, you can now easily get a free, valid 1-year SSL certificate that has a root certificate that is baked into every major web browser and OS.

The Login System

The login system is the weakest entry point of the Barebones CMS. A script kiddie that finds the login system will generally have a lower barrier to entry than through other means (packet sniffing requires sitting on the same network and usually close proximity and all links use security tokens making both generally harder routes). As such, you are encouraged through various means to move it into a more secure location. This procedure is well-documented:

Installing and Upgrading Barebones CMS

Once logged in, a user can edit any portion of the site under the control of the CMS. Developer accounts are incredibly powerful and can do anything in the system including author PHP code that is executed on the server. Be sure that all Developer accounts use hard to guess usernames and completely random passwords.

If you already have a login system you wish to use for the purpose of logging in and editing content in Barebones CMS, you can integrate your login system into the Barebones CMS login system by creating a 'login_hook.php' file in the same directory as 'login.php'.

The Code Widget

Three widgets accompany the baseline Barebones CMS installation. The Code widget is perhaps the most blatant security vulnerability - it lets you enter executable PHP code right inside the browser.

If you never plan on using the Code widget, deleting it is the recommended course of action to significantly reduce the potential attack surface of Barebones CMS.

Easy Edit

The Easy Edit feature of the Barebones CMS system can be considered a security vulnerability. Easy Edit is the functionality that puts the "Edit" link in the upper-right corner of the page on the public side of things. The link itself isn't vulnerable but it reveals that every page in the CMS is a potential entry point into the editing interface.

There are several built-in mitigation techniques to minimize the possibility of severe vulnerabilities. Security tokens (aka "nonces") are used extensively - every clickable action requires a unique token. The critical login token 'bbl' is kept as a "HTTP Only" cookie. Some browsers do not keep 'bbl' secret and Barebones will warn the user that their browser is insecure. Even with these measures, it is still theoretically possible to generate a working access token.

To mitigate this issue, it is recommended that a plugin be written that checks for valid IP address ranges. That way, even if a correct login token is guessed, the hacker will still be outside of the valid IP address range to actually get into the system. Of course, this is useless if the editor isn't being run over SSL.

Untrusted Users

Barebones CMS assumes that the people you work with are trustworthy. If you can't trust the people who will be working within this system, then do not use Barebones CMS. The best way to mitigate this issue is to train users to use the CMS in a responsible fashion.

Shortcode Security

Part of the Content widget's responsibilities is to display placeholder icons wherever a Shortcode's content would appear. This is to prevent Shortcodes from being a privilege escalation vector from within the editor.

It is highly recommended that Shortcodes always show placeholders for Developer accounts. This significantly reduces the attack surface from within the Preview Frame with Shortcodes. The strictest environments should show placeholders for all account types. Showing placeholders allows for faster Preview Frame reloads as it tends to reload quite frequently. However, placeholders make it more difficult to see what the final content will look like.

Many Shortcodes offer "local" vs. "remote" security options. You may opt to show content hosted locally but not remotely. Content on remote (usually untrusted) servers will get a HTTP "referer" containing the URL of the Preview Frame, which includes a security token. It may be possible to reverse-engineer a Preview Frame security token to create tokens for other commands, but highly unlikely. The remote server would be missing several critical pieces of information. Nonetheless, keep this issue in mind for remotely hosted content in Shortcodes.

© CubicleSoft