Tighten Your CMS Security

Every CMS allows administrators to set permissions for different users or groups and, for the sake of better security, one should check that editors can only do what they are supposed to. It's not a matter of lack of trust; even if we are sure that editors won't do anything wrong, we may not be so sure about the strength of their security measures. A malicious attacker can break in, take control and use editor's privileges; that's why it is essential that he has no access to potentially harmful features, that are not relevant to his everyday work. Typical case in point: someone who's working solely on content should not be able to inject any JavaScript code on the page.

Scrivito manages permissions in a very powerful and sophisticated way; you can refine the privileges individual users have regarding working copies, even prevent particular pages from being published by specific editors. Setting this up is not one of the easiest tasks, but this is an acceptable trade-off for improving security policies, while leaving the editors all the privileges they need to use a product like Scrivito at its best.

So-called cyber attacks can be very sophisticated, and setting a permission policy may not be enough to stop a break attempt through Cross-Site Scripting (XSS). The attacker can hide malicious code in several places inside the page: from inside the obvious script tag through an unsuspecting HTML comment. Tag and attribute names are places where you should never put untrusted code. Since the malicious code is stored on the same server as the source page, the browser has no means to identify it as dangerous and, generally, it tries to attack a user with higher privileges in order to execute more harmful commands. Once the hacker's code is safely stored on the same server (bypassing the same origin policy control), it has almost free rein to go around unnoticed.

The defence against these attacks is to implement a Content Security Policy (CSP) instead of blindly trusting everything that a server delivers. CSP defines the Content-Security-Policy HTTP header that allows you to create a whitelist of sources of trusted content and instructs the browser to only execute or render resources from those sources. Even if an attacker can find a hole through which to inject a script, the script won’t match the whitelist, and therefore won’t be executed.

In addition to restricting the domains from which content can be loaded, the server can be allowed to use only specific protocols; for example it can specify that all content must be transmitted using HTTPS.

CMSs are complex systems that manage a large quantity of data and must give users a high degree of editing freedom; their relatively open architecture makes them an interesting target for hackers. Proprietary products are generally considered more secure than open-source ones, where hackers can inspect the public code and easily search for vulnerabilities, but that does not mean that a proprietary CMS has no vulnerabilities and that you can let your guard down. Following these simple but effective rules can help to improve the security of your data.

Regular maintenance of any CMS is mandatory to keep security at a high level. Most administrators are reluctant to implement updates and patches, because they fear that some plugins they're using may stop working, so they wait for other users’ feedback. But this delay works well on the hackers' side, since they can exploit the holes that have not been patched as people stand by waiting to install an update.

One good point in choosing a cloud hosted CMS is that you don't have to care about updates; they are applied automatically. Scrivito is a SaaS product; you as a customer don't update the CMS. This is our responsibility and we’re taking it very seriously. Nonetheless, you should keep the application connecting to the CMS up to date. We regularly provide new versions of the Scrivito SDK, which not only contain new features, but also security updates.

Also you should regularly update any software installed on the servers hosting your application as well as the server software itself. This is what we do for you if you decide on a hosting packages with us.

Most CMSs use plugins to extend their possibilities far beyond what the core offers. Despite the clear advantages this modular approach offers, plugins should be used sparingly since they are the main source of security flaws. Often they are created by a very small team, if not by a single programmer, with not enough resources to evaluate security flaws properly.

What we’ve said above about plugins also applies to Scrivito gems. The Ruby gems are a wonderful way to extend Scrivito’s possibilities and your applications, but they obligate you to apply patches and updates as frequently as possible. Good practice is to check how seriously they are maintained, when the last release was, and if the maintainers promptly react to issues.

As you may guess, you can have the same kind of issues with JavaScript libraries as well: they are probably essential to your project but they also can be an excellent vehicle for malicious code.

There are some typical default usernames, like “admin”, that can be easily guessed, thus saving some work for the hacker who attempts a brute-force attack. Replacing them with something not as easy to guess is a wise idea.

Sometimes error messages give out too much information and can inadvertently ease the job of someone trying to do complex attacks like SQL injection.

Since Google had announced that adding an SSL certificate to your website actually would give it a ranking boost (and that users are warned if they're browsing a non-secure website), switching to HTTPS has become kind of mandatory for most websites. But, next to the ranking increase benefits, there are lots of valid reasons to switch to HTTPS:

Everybody knows that passwords are the greatest weak spots, but most people without knowledge in security aren't fully aware how insecure their passwords can be and how big the risks actually are. As mentioned above, certain attacks on low-level users can jump even to the admin level, so even just one user with a weak password can put the whole system at risk. Practices like allowing only very long passwords, case sensitive and with special characters, although they may bother users, are just the first unavoidable step towards better security.

For more tech-savvy admins, password encryption offers a good level of security. In the unfortunate event that someone breaks in and steals the passwords, they cannot be decrypted if they are hashed . They are still exposed to a dictionary or brute force attack though: in that case, using salted password makes the cracking computationally very expensive. Salting is a technique that adds random data unique to each user and saves it with their password for the hashing process. The salt completely changes the output of the hash function, rendering the typical cracking method of the rainbow table completely useless.

Even for a system with all security measures properly applied, the weakest part of any security implementation is the human factor. The most sophisticated security technologies are useless if someone writes down his passwords on a post-it attached to their desk, exposed to everybody's eyes. Therefore, one crucial aspect to be considered for better security is to instill a security culture in the whole team, so that everybody contributes to tightening the security of the entire system.