5 Tips to Secure Your Kentico Sites

Because Kentico EMS is a .NET application, it’s as secure as nearly every other Microsoft stack application. It’s also just as vulnerable to bad configuration and implementation.  While developers can write secure code to prevent SQL injection, XSS, and other known techniques, a bad configuration can derail the security of a site faster than anything.

Because Kentico runs on top of IIS, there are several areas you need to consider when hardening your sites from nefarious folks.  These include security and permissions, storing sensitive information, and how much access you give the user from within the site. Because there are so many parts you should address, we have several checklists in our documentation to help you make sure your application is locked down.

You can find out more about the Kentico Security Checklists here.

While there are many great tips in those checklists, I wanted to highlight a few, as well as add a couple in this article. Security is a never-ending job, so educating yourself on every aspect is critical to ensuring your application is and stays up to date!

1. Locking down cookies

OK, to start the list I want to go with a simple one. For over 20 years, websites have been using cookies to store and track user activity on sites. They also can contain a startling amount of personal information about the visitor, which makes them a common target for hackers. You can leverage some built-in .NET capabilities to make sure their cookie data is only readable by the application.

To secure your cookies, you should:

• Mark your cookies as httpOnlyCookies=true
  This setting tells the application that only the server can access the cookie data, and prevents any other method of viewing the information.
• Configure requireSSL=true for your cookies
  This setting requires SSL to be used when accessing cookies. This prevents unauthorized viewing of the data when the information is accessed.

You can set these configurations in the web.config file like this:

You can find more about this in our documentation here.

2. Restrict access to directories

Another area noted in our document is restricting access to directories. Because savvy hackers know many people overlook this area, they can easily scan a directory or folder within the site and access sensitive information with a simple loop.  By locking down your IIS, you can prevent this vulnerability and ensure users can only get to the approved areas of the site.

You find out more about locking down directory access in our documentation here.

3. Store appSettings and connectionStrings in external files

Not all threats come from outside your organization, or are even threats to begin with. Sometimes, you need to ensure your sensitive settings and configurations are stored and managed properly within your organization.  By keeping your sensitive information secured, you can make sure the wrong code isn’t deployed or accessed by unauthorized people. Because Kentico is .NET-based solution, again, it comes with some cool capabilities to store your application settings and connection strings in separate files. 

appSettings

To store your appSettings in a separate file, you need to do the following.:

• Create a new AppSettings.Config (or similar name) in your project
• Copy your sensitive settings to the file, along with the wrapping <appSettings > tag
• Update your web.config files to reference the new file
• Exclude the AppSettings.Config file from your source control

Here is a sample web.config section.

Here is a sample AppSettings.Config file.

A few notes about appSettgings values:

• You generally only want to store sensitive information in the separate file. You can keep non-sensitive settings in your web.config.
• You will generally want to exclude the AppSettings.Config file from source control. This prevents anyone from checking in sensitive information into your repository.
• The file property is specific to the appSettings section. This will allow .NET to merge the separate file contents with the existing appSettings section in the web.config. This allows you to update the separate file without requiring an IIS restart.

connectionStrings

To store your connectionString values in a separate file, do the following:

• Create a new ConnectionStrings.Config (or similar name) in your project
• Copy all your connectionStrings to the file, along with the wrapping <connectionStrings> tag
• Update your web.config files to reference the new file
• Exclude the ConnectionString.Config file from your source control

Here is a sample web.config section:

Here is a sample ConnectionString.Config file:

A few notes about connectionStrings values:

• You will generally want to exclude the ConnectionStrings.Config file from source control. This prevents anyone from checking in sensitive information into your repository.
• The configSource property is used to replace all values for the section. This means all connection strings will be loaded form the separate file. If a connection string of the same name exists in the web.config and external file, the value in the external file will be used.
• Updating the separate connection string file will cause an IIS restart.

You can check out Kentico Consultant Chris Jennings’s article on this process here.

4. Encrypt connectionStrings

Connection strings can be further secured by encrypting their values. This process leverages built-in .NET functionality to encrypt the connection strings so that they are only readable by the server. This takes security to another level by ensuring only someone with direct server access can ever view the information.

To encrypt your connection strings:

• In a command window, browse to the C:\Windows\Microsoft.NET\Framework\v4.0.30319 folder
• Execute the following command to encrypt your connection string values, using your site’s root directory for the path
  • ASPNET_REGIIS -pef "connectionStrings" "[Path to application root]" -prov "DataProtectionConfigurationProvider"

This command will update your web.config (or external ConnectionString.Config file) with an encrypted version of your connection strings.

<connectionStrings configProtectionProvider="DataProtectionConfigurationProvider">   <EncryptedData>     <CipherData>       <CipherValue>AQAAANCMnd8BFdERjHoAwE………….</CipherValue>     </CipherData>   </EncryptedData> </connectionStrings>

A few notes:

• The connectionStrings are decrypted on the fly by .NET when they are requested within your application.
• The ASPNET_REGIIS command can be used to decrypt the values in the file if needed.
• The above sample uses the DPAPI provider for encryption. This offers better security, but is incompatible with web farms. If you need to encrypt in a web farm environment, use the RSA provider instead.

You can find out more about connection string encryption here.

5. Azure App Service Settings

If you are hosting your application in Azure App Services, you can take advantage of cloud-based Application Settings to store your sensitive information. This allows you to deploy your applications without any sensitive information and manage all the values from within the Azure portal.

You can find out more about this process in my previous blog here.

Moving forward

In this blog, I covered several areas you should consider to ensure your application is secure. I hope this helps you in locking down your sites and preventing unauthorized access to your sensitive data. From password policies to UI permissions, there are many other areas you will need to think about. Be sure to educate yourself on all the security measures .NET and Kentico offer in our documentation and online.  Good luck!