10 Rules to make sure your security is set up right

Hi there,

Time to time, we provide support to a client that is all about setting up the web site. The web site is looking pretty and clean, but they somehow forget about setting up the security which puts them in vulnerable position without them even knowing.

Setting up security on the infrastructure level could be a chapter itself, with all the DMZs and stuff, so I will keep this brief so it can cover the most important aspects of it, mostly the ones specific to Kentico CMS, where it can help you or where you should take some steps.

Let's consider the standard scenario where you start working with Kentico CMS and install a sample web site, then just modify it and put it live for the client ...

Rule 1 - Be paranoid

Being paranoid doesn't neccesarily mean that you are considered crazy by others. It may save your data and your job if you consider the effects of somebody breaking into your system. Always proactively search the potential ways how somebody could access your system and close the doors for them. Even though Kentico CMS in comparison to other solutions doesn't have any serious security bugs reported, it doesn't mean it will protect you from allowing the attackers to do something if you configure something improperly.

Rule 2 - Avoid sample users and roles

As you know, our sample web sites come with sample users and roles that anyone can use to demonstrate the features. Since some of them are editors and some of them are global administrators, they may be a potential entry into the system. So the very first thing before you put your site live is making sure that you deleted all the unwanted sample users and roles or at least made sure that they are limited with the permissions you want to.

Rule 3 - Avoid empty or default passwords

Not only with the default installation, but also after your development or testing, you may have some sample users within your database that either do not use any password at all, or use just a simple password, and they may be users with high privileges. Before you put your site live, you should make sure that every user in the database has some password set and that password is complex enough according to the rights the person has. The "public" user is safe and doesn't need any adjustments, it just states for any anonymous user.

Rule 4 - Avoid default or testing e-mails

Sample or testing users may also use sample e-mail addresses or an e-mail address that points to a non-existing domain. That is the case of older versions of Kentico CMS (around 4.x), where the e-mail of sample users was like system@mydomainxy.com. It was OK until the domain was not taken, but later, someone registered the domain name and suddently got spammed from all the sample installations that sent e-mails to that default addressed. Needless to say, this doesn't include just sample workflow notifications and similar e-mails, but also the password reset notifications, which makes the system much more vulnerable if that refers to an account with some admin permissions. That is basically why we changed the default mails to point to localhost.

NOTE: If you use Kentico CMS 4.1 or sooner, make sure you don't have the e-mails <something>@mydomainxy.com in the settings of your users.

One way or another, before you put your site live, you should check if all your users have proper e-mail addresses set and you don't have any users with testing e-mails.

Rule 5 - Secure logon process

Based on how secure you need your web site to be, ou may want to implement SSL for your logon pages. Usage of SSL is sometimes required, because without it, anyone on the line (Man in the middle) can potentially listen to the HTTP request and listen to the value of the password box. Kentico CMS provides two ways:

1) SSL for the live site UI, which you can configure in the document properties, see this for details:

http://devnet.kentico.com/docs/devguide/index.html?ssl_https_support.htm

2) SSL for the admin logon which you can configure in the web.config just by modifying the forms authentication config

<forms loginUrl="CMSPages/logon.aspx" ... requireSSL="true" />

Find more details here: http://msdn.microsoft.com/en-us/library/ff648341.aspx

Rule 6 - Implement secured areas

Your web site may contain information that should just be accessible by someone. In that case, you need to make sure those areas will require authentication and check the permissions accordingly. Kentico CMS provides you with a way how to easily set that up so go ahead and leverage that features:

http://devnet.kentico.com/docs/devguide/index.html?secured_web_site_areas.htm

Rule 7 - Validate and sanitize the inputs

Typical project isn't only a set of defined URLs, but the pages are somehow dynamic based on parameters. Those parameters can be parts of the URL, or the user input from any form. Sanitizing such data can protect you from unwanted Cross Site Scripting (XSS) attacks on your visitors or SQL injection. Kentico CMS allows you to sanitize the macros coming from various sources with SQL injection handling and by means of casting the values to the correct types, e.g. {%newsid|(toint)%}. More about available macro conversions here: http://devnet.kentico.com/docs/devguide/index.html?appendix_a___macro_expressions.htm

In the code and transformations, you can just cast the values with our ValidationHelper class methods, and in transformations, you can encode the HTML code by standard means or with our HTMLHelper class to prevent XSS.

Rule 8 - Protect data and file storage

You may place your hardware into Himalayas, being guarded by an army of robots, but it won't protect your servers from being accessed through the network. You simply cannot just cut off the whole line, because the world needs to see your web site. What you need to do is secure any other possible ways into your project. One of them surely is the FTP connection, which ships the password in a plain text format and was a very bad solution even back in the 90's. You should use at least SCP or SFTP which can be secured. Similar, yet different thing with your SQL server. Why allowing anyone to access it from anywhere if you can restrict it just for access from your specific local IP address where you really use it? Is really any port on your server needed or can it just be port 80 for HTTP requests? Those are the questions you should ask yourselves and consider while planning security around the project itself.

Rule 9 - Watch and check suspicious activities on the web site

Typical attack to your website consists of:

• Information gathering
• Attempts to break through the security
• Harmful actions once the user gets there

Once the hacker performs the harmful action, you may just want to drop the data, because you never know what is left in there if your project is too big and he could just have left there some back door in it. So you need to prevent this in sooner phases of the attack. You can take advantage of Kentico CMS Event log, and identify potential attempts to break the security. If there are too many tries to do something or too many errors logged from a single IP address (or a subset of addresses), it may be the result of a brute force attack to your infrastructure. You should also inform your users to report any suspicious activity like somebody asking their credentials etc. Only that way, you can catch the thief soon enough.

Rule 10 - Backup your project

No matter how secure your web site is, it is possible that it may eventually be hacked. It doesn't have to come from an external source, it may be compromised by your former employee that got access to all your passwords or their IP is still allowed on the firewall. Or it may simply be an attack from somebody way more experienced than anyone else on your site so they can get through your security rules. For those purposes, it is always good to have your backups stored separately, not accessible through network or in the same building, but close enough so you can quickly restore during a tragic event. You can either backup the whole database, or just particular sites or objects with our import/export functionality.

More details on import/export here: http://devnet.kentico.com/docs/devguide/index.html?export_and_import_overview.htm

Rule 1x - Never consider the list of rules final

The list isn't ending, there are numerous other things that you could consider, these are only the basics to make sure the beginner hackers can't get access your project. It is only up to you which are the ways to access your project, and it is up to you to make sure that they are secured ...

We are doing the best we can to provide you with more reminders and ways how to set it up in a easier way, there will be improvements in 6.0, too, but the final action is yours ... ALWAYS!

See you next time ...