Why mojoPortal? Part One: Core Security

 

As some readers may know, I've been active with the mojoPortal project since 2011. This is part one of a blog series about the mojoPortal Content Management System, and why you might want to choose it to run your own web site.

 

I decided to post about security first, because many people likely consider security last when they are evaluating a CMS. Other CMS projects offer features like "one click" upgrades, or executable plug-in installers. People often don't realize that along with the convenience that features like these offer comes a high level of risk. Because if an administrator of a site can upload and execute code through the web server itself, then an attacker wielding an exploit can do the same.

So rather than allowing this convenience, mojoPortal requires that you either use the Web Platform Installer, or upload the CMS or add-on module through a separate means, such as FTP. After the files are uploaded, you navigate to the Setup page to install it into your site. Along with this, mojoPortal advocates that you specifically deny the web server the ability to write to any folders but App_Data and Data, where site skin and other media files sit. On top of that, you should even prevent files from being executed in these data folders. This way, if an exploit occurrs, the attacker will not be able to modify the CMS code itself in order to cause harm or install backdoors into your site.

Based on this core security philosophy of mojoPortal, the hypothetical CMS shopper might think:

But I trust CMS X's team of programmers. I know they'll keep the attackers out, and I have strong passwords, so I don't have to worry about it. mojoPortal is too hard to customize and upgrade. Bring on the convenience!

Well, I hate to be the one to break it to you, but the coders of the CMS are not necessarily going to be the ones responsible for your site getting "pwned." In fact, a mistake on their part might not even be the most likely route to a site compromise. Maybe your password falls into the wrong hands. Maybe the attackers figure out a way to exploit your web server and make it overwrite or delete executable files for your site. Whichever way they do it, the underlying attack method ultimately relies on the ability of the web server to write to disk locations containing the site's executable files.

For more reading about this topic, check out the Installing mojoPortal documentation at mojoportal.com

Posted by Jamie Eubanks Wednesday, May 7, 2014 12:37:00 PM Categories: CMS mojoPortal Security

Comments

You must sign in to this site to post comments.
Already Registered?
Sign In
Not Yet Registered?
Register