Security in Sitecore: An Expert Guide

 

Introduction

In the ever-evolving digital landscape, securing web applications is of paramount importance. Sitecore, a powerful and flexible digital experience platform, offers a comprehensive set of tools and features to ensure the security of your website and data. This article aims to provide an in-depth understanding of security in Sitecore, covering best practices, configurations, and advanced strategies to protect your Sitecore environment.

The Importance of Security in Sitecore

Security is crucial in protecting sensitive data, maintaining the integrity of your website, and ensuring compliance with regulatory requirements. Security breaches can lead to data loss, financial loss, and damage to your organization's reputation. Sitecore provides robust security features to safeguard your content, user data, and application, making it an essential aspect of your overall digital strategy.

Database security recommendations

It focusses on protecting your data both at rest and in motion.

To secure data transmission between an instance of SQL Server and a client application (data in motion or transit), use Transport Layer Security (TLS) to encrypt the connection.

To secure physical files, such as data and log files (data at rest), use Transparent Data Encryption (TDE). TDE is configured on the SQL Server side and does not require any specific Sitecore configuration settings. TDE is enabled by default for newly deployed Azure SQL databases, but it is not enabled by default for on-premises deployments.

Important: TDE does not encrypt the communication channel or the data itself, meaning that anyone with database access can still read sensitive data.

For encrypting sensitive data at rest, use the Always Encrypted feature. This feature ensures a separation between those who own and process the data and those who manage it but must not access sensitive information. Only the client application can decrypt and utilize sensitive data.

Always Encrypted configures encryption for individual database columns containing sensitive data, so not all columns may be encrypted.

Note: Not all Sitecore databases support the Always Encrypted configuration. Supported Sitecore databases include the xDB Collection database and the Sitecore Cortex Processing database.

Control User Access to Web Resources

You can configure access privileges for web resources using the <location> tag in the Web.config file. The following example denies access to the /sitecore path for all users except for admin and webmaster:

<location path="sitecore">

<system.web>

<authorization>

<deny users="*"/>

<allow users="admin, webmaster"/>

</authorization>

</system.web>

</location>

You can also configure the Web.config file to use Windows ASP.NET groups and users. 

Note: By default, only Core roles use the <location> tag, and each Core role is configured differently. We recommend auditing your location tags as part of your security review process.

Update the Administrator Password

Prior to deploying your Sitecore installation, it is essential to change the administrator password to a strong, secure password. This helps prevent unauthorized users from accessing the admin account using the default password.

Create a New Administrator Account

For additional security, Sitecore recommends creating a new administrator account with a unique name and disabling the default administrator account. This provides an extra layer of protection.

Update the Hash Algorithm for Password Encryption

By default, Sitecore uses the Microsoft ASP.NET membership provider for user management.

When setting up a new website, it is crucial to replace the default weak hash algorithm (SHA1) used for encrypting user passwords with a stronger one. 

Steps to Change the Hash Algorithm:

1. Log in as an administrator:

• Ensure you are logged in as an administrator while the SHA1 configuration is still active in both Sitecore XP and the Identity Server.

2. Modify the configuration files:

• Ensure both Sitecore and the Identity Server use the same hash algorithm setting.

3. Update the web.config file:

• In the <membership> node, set the hashAlgorithmType to a stronger algorithm. We recommend using SHA512.

4. Update Sitecore Identity Server:

• If you are using Sitecore Identity, you must also change the algorithm in the Identity Server configuration. Specify the algorithm in the PasswordHashAlgorithm node to SHA512 in the \sitecore\Sitecore.Plugin.IdentityServer\Config\identityServer.xml file.

5. Restart the Identity Server:

• Restart the Sitecore Identity app service.

6. Change the admin password:

• Use the User Manager application to update the admin password so that it is hashed with the new algorithm.

Note: After changing the hash algorithm, you cannot manually type a new admin password to change it. Instead, click "Generate" to create a new hashed admin password.

7. Update other user passwords:

• Ensure all user passwords are updated to be hashed with the new algorithm.

Enabling and Disabling Administrative Tools

Sitecore administrative tools can be helpful for troubleshooting issues in a production environment, but for security reasons, you must:

• Always disable them as part of the deployment process.

• Always disable them when they are not in use.

• Never enable them on the Content Delivery and xDB Processing roles. It's safe to delete the administrative tools folder on these roles.

• Only enable them on Content Management roles that are not exposed to the internet.

Administrative tools are ASPX files with .aspx extensions, located in the <webroot>\sitecore\admin\ folder and its subfolders.

Disabling an Administrative Tool

To disable an administrative tool:

1. Navigate to the administrative tools folder.

2. Click on the tool you want to disable.

3. Add .disabled to the tool's filename. For example, rename cache.aspx to cache.aspx.disabled.

Admin files

Disabling Client RSS Feeds

If your Sitecore installation contains sensitive information that you want to protect, you can disable the Sitecore client RSS feeds.

RSS technology allows users to follow an RSS link directly to the item specified in the feed's URL. Most RSS readers do not support authentication, meaning users subscribed to Sitecore client RSS feeds can access the specified items directly without identifying themselves through the Sitecore security system. However, the Sitecore security system verifies user authorization when they attempt any actions associated with the client feed.

If an unauthorized user gains access to the URL of a client RSS feed:

• They can follow the link and view all the content in the client feed, even if their security permissions do not grant access to the item.

• They cannot perform any actions on the content.

• They cannot view any other content.

• They cannot gain access to the username or password of the original feed owner.

• They cannot modify the link to access other content.

Important: Sitecore users should not share client RSS feeds.

To disable Sitecore client RSS feeds:

1. Open the web.config file.

2. Locate the <httpHandlers> section (it may be called <Handlers> depending on your IIS pool).

3. Remove the following handler:

<add verb="*" path="sitecore_feed.ashx" type="Sitecore.Shell.Feeds.FeedRequestHandler, Sitecore.Kernel"/>

Removing this handler disables all client feeds available within Sitecore. Any public RSS feeds you have created will still be accessible to website visitors.

Disabling SQL Server Access from XSLT

Sitecore includes an xslExtension helper for use with SQL Server. It is strongly recommended to disable this helper if:

• You do not need it.

• You are not using Sitecore XSLT renderings.

To disable the xslExtension helper:

1. In the App_Config/Include folder, create a patch file. Name the file with a .config extension.

2. Insert the following code into the patch file:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">

<sitecore>

<xslExtensions>

<extension type="Sitecore.Xml.Xsl.SqlHelper, Sitecore.Kernel">

<patch:delete/>

</extension>

</xslExtensions>

</sitecore>

</configuration>

Enhance Login Security

You can enhance the security of the Sitecore login page by taking the following steps:

1. Enable SSL: Make the login page accessible only through SSL.

2. Turn off autocomplete for usernames: Prevent Sitecore from automatically completing usernames during login. This is especially useful if content authors log in from shared or public computers.

3. Disable the "Remember me" checkbox: Remove the option for users to save their login credentials on the login page.

Steps to Implement:

1. Turn off autocomplete for usernames:

• Open the sitecore.config file.

• Set the Login.DisableAutoComplete setting to true. This disables autocomplete on the Sitecore login forms located at /sitecore/login/default.aspx and /sitecore/admin/login.aspx.

2. Disable the "Remember me" checkbox on the login page:

• On the Sitecore Identity Server role, open the sitecore/Sitecore.Plugin.IdentityServer/Config/identityServer.xml file.

• Set the AllowRememberLogin setting to false. This also ignores any existing "Remember me" cookies, requiring all users to log in again.

3. Disable the "Remember Last Logged In User Name" setting:

• Open the sitecore.config file.

• Set the Login.RememberLastLoggedInUserName setting to false. This prevents the browser from remembering the username of the last logged-in user.

Implementing these measures will significantly improve the security of your Sitecore login process.

Restrict Access to XML, XSLT, and MRT Files

To enhance the security of your Sitecore installation, you should limit access to XML, XSLT, and MRT files. This involves editing the web.config file with general Sitecore settings and disabling the web.config file with EXM settings.

Steps to Limit Access:

1. Open the web.config file with general Sitecore settings:

• This file is located in the top-level folder of your installation or in the Website folder.

2. Add the following lines in the <system.webServer><handlers> section:

<system.webServer>

<handlers>

<add path="*.xml" verb="*" type="System.Web.HttpForbiddenHandler" name="xml (integrated)" preCondition="integratedMode"/>

<add path="*.xslt" verb="*" type="System.Web.HttpForbiddenHandler" name="xslt (integrated)" preCondition="integratedMode"/>

<add path="*.config.xml" verb="*" type="System.Web.HttpForbiddenHandler" name="config.xml (integrated)" preCondition="integratedMode"/>

<add path="*.mrt" verb="*" type="System.Web.HttpForbiddenHandler" name="mrt (integrated)" preCondition="integratedMode"/>

</handlers>

</system.webServer>

This configuration restricts access to all XML, XSLT, and MRT files.

3. Disable the web.config file with EXM settings:

• This file is located in the \sitecore modules\Shell\EmailCampaign\ folder.

Allow Unrestricted Access to a Specific File Path

After restricting general access, you might need to allow access to specific files.

1. Open the web.config file with general Sitecore settings.

2. Add the following line before the handlers that limit access:

<add path="sitemap.xml" verb="GET" type="System.Web.StaticFileHandler" name="xml allow" />

Replace sitemap.xml with the specific file to allow unrestricted access to.

Restrict Access to PhantomJS

By default, PhantomJS is not disabled on Content Delivery, xDB Processing, and xDB Reporting roles. It is used by Sitecore for content testing and generating thumbnails. To enhance security, you should move PhantomJS outside the webroot folder, limit its permissions, and disable it on roles where it is not needed.

Steps to Secure PhantomJS:

1. Move PhantomJS Outside the Webroot Folder:

• By default, PhantomJS is located in the <webroot>\$(dataFolder)\tools\phantomjs\ folder. The $(dataFolder) variable defaults to App_Data, placing PhantomJS in <webroot>\App_Data\tools\phantomjs\.

• This location can potentially expose the phantomjs.exe program file if Sitecore security settings are not properly configured.

2. Update Configuration Settings:

• Sitecore references PhantomJS for content testing through the ContentTesting.PhantomJS.ExecutablePath setting in the <webroot>\App_Config\Sitecore\ContentTesting\Sitecore.ContentTesting.config patch file.

• For thumbnail generation, Sitecore uses the following settings:

• PhantomJsExePath references the phantomjs.exe file.

• PhantomJsRenderScriptPath references the render.js file.

Example Configuration to Move PhantomJS:

1. Move the PhantomJS Folder:

• Move the <webroot>\App_Data\tools\phantomjs\ folder to a new location, such as C:\phantomjs1\. Optionally, you can define separate folders for content testing and thumbnails (e.g., phantomjs1 for content testing, phantomjs2 for thumbnails).

2. Create a Patch File:

• In the <webroot>\App_Config\Include\ folder, create a patch file named MovePhantomJSFolder.config.

• 
  

3. Insert the Following Configuration:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/" xmlns:security="http://www.sitecore.net/xmlconfig/security/">

<sitecore>

<settings>

<setting name="ContentTesting.PhantomJS.ExecutablePath" value="C:\phantomjs1\phantomjs.exe" />

<setting name="PhantomJsExePath" value="C:\phantomjs2\phantomjs.exe" />

<setting name="PhantomJsRenderScriptPath" value="C:\phantomjs2\render.js" />

</settings>

</sitecore>

</configuration>

4. Move Contents from the App_Data Folder:

• Transfer the contents from the App_Data folder to the new data folder (e.g., D:\SC\Data).

5. Important Considerations:

• The App_Data folder is defined by default in the dataFolder variable in the Sitecore.config file.

• When creating a new location for PhantomJS.exe (e.g., C:\PhantomJs), ensure only the files originally found inside the <webroot>\App_Data\tools\phantomjs folder are moved to the new location.

By following these steps, you can secure your Sitecore installation by limiting access to PhantomJS and reducing potential vulnerabilities.

Protect Media Requests

The media request protection feature in Sitecore restricts media URLs with dynamic image-scaling parameters, ensuring that only valid server-generated requests are processed. This helps optimize server resource usage and disk space by avoiding unnecessary processing of invalid requests.

To enhance the security and functionality of media request protection, you can patch the Sitecore.Media.RequestProtection.config file.

Steps to Optimize Media Request Protection:

1. Create a Patch File:

• In the App_Config\Include\ folder, create a new patch file named MediaRequestProtectionSecret.config (or another name of your choice).

2. Insert the Configuration Code:

• Add the following code to the patch file:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">

<sitecore>

<settings>

<setting

  name="Media.RequestProtection.SharedSecret" value="YourRandomGeneratedString"/>

</settings>

</sitecore>

</configuration>

3. Save the Patch File:

• Save the newly created patch file to apply the changes.

Important Note:

• Consistency in Multi-Server Environments:

• In a multi-server setup, the same Media.RequestProtection.SharedSecret value must be used across all servers. This ensures that dynamic image scaling works correctly, regardless of which server generates the image URL and which server handles the request.

By implementing these changes, you can strengthen the protection of media requests and ensure efficient and secure handling of dynamic image-scaling requests in your Sitecore environment.

Remove Header Information from Responses

Enhancing security and saving bandwidth can be achieved by removing header information from responses sent by your website. These headers often reveal details about your website's framework that are unnecessary to disclose.

Remove the X-Aspnet-Version HTTP Header

The X-Aspnet-Version header reveals the version of ASP.NET being used, which can be useful for potential attackers. By removing this header, you not only save a small amount of bandwidth but also obscure this information.

To remove the X-Aspnet-Version HTTP header, add the following configuration to your web.config file:

<system.web>

<httpRuntime enableVersionHeader="false" />

</system.web>

Remove the X-Powered-By HTTP Header

The X-Powered-By header indicates which version of ASP.NET is being used. Removing this header helps prevent the exposure of this information.

To remove the X-Powered-By HTTP header, include the following code in your web.config file:

<system.webServer>

<httpProtocol>

<customHeaders>

<remove name="X-Powered-By" />

</customHeaders>

</httpProtocol>

</system.webServer>

Implementing these changes will contribute to your website's security by obscuring the details of your framework and saving a minimal amount of bandwidth.

Restrict Access to the Client

Disable Forms Authentication

To ensure Sitecore does not handle any authentication requests, you can disable Forms authentication.

To disable Forms authentication:

1. Open the <webroot>\Web.config file.

2. Locate the <authentication> node.

3. Modify the mode attribute from Forms to None.

<authentication mode="None" />

Deny Access to the Copyrights Folder

The sitecore/Copyrights/ folder on the CD server contains license text files for third-party components used by Sitecore. To prevent unauthorized access to this folder, configure Sitecore to deny access.

To deny access to the folder:

1. Add the following setting to the <handlers> section of the web.config file on your CD server:

<add name="StopSitecoreCopyrightsDirectoryBrowsing" path="sitecore/Copyrights/*" resourceType="Directory" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler" />

These measures will enhance security by restricting unauthorized access and ensuring that authentication requests are handled appropriately.

Disable the Upload Watcher

To ensure that files can only be uploaded to Sitecore through the Media Library and to maintain control over file uploads, you should disable the Upload Watcher. This will prevent automatic uploads of files placed in the upload folder to the Media Library.

To disable the Upload Watcher:

1. Open the web.config file.

2. Locate the <system.webServer><modules> section.

3. Remove the following line:

<add type="Sitecore.Resources.Media.UploadWatcher,Sitecore.Kernel" name="SitecoreUploadWatcher" />

By disabling the Upload Watcher, you restrict file uploads to the Sitecore client interface, ensuring better management and security of uploaded files.

Secure Telerik Controls

Sitecore utilizes certain Telerik UI controls, which are only employed in a Content Management environment. To minimize security risks:

1. In Non-Content Management Environments:

• Open the web.config file.

• Remove the following nodes:

<add name="Telerik_Web_UI_DialogHandler_aspx" verb="*" preCondition="integratedMode" path="Telerik.Web.UI.DialogHandler.aspx" type="Telerik.Web.UI.DialogHandler" />

<add name="Telerik_Web_UI_SpellCheckHandler_axd" verb="*" preCondition="integratedMode" path="Telerik.Web.UI.SpellCheckHandler.axd" type="Telerik.Web.UI.SpellCheckHandler" />

<add name="Telerik_Web_UI_WebResource_axd" verb="*" preCondition="integratedMode" path="Telerik.Web.UI.WebResource.axd" type="Telerik.Web.UI.WebResource" />

2. In Content Management Environments:

• Configure the encryption keys for the Telerik upload control by modifying the web.config file.

• In the <appSettings> section, add nodes for the Telerik configuration encryption keys:

<appSettings>

<add key="Telerik.AsyncUpload.ConfigurationEncryptionKey" value="YOUR_ENCRYPTION_KEY_HERE" />

<add key="Telerik.Upload.ConfigurationHashKey" value="YOUR_ENCRYPTION_KEY_HERE" />

<add key="Telerik.Web.UI.DialogParametersEncryptionKey" value="YOUR_ENCRYPTION_KEY_HERE" />

</appSettings>

• Replace YOUR_ENCRYPTION_KEY_HERE with a secure string of random characters and numbers. The key should be at least 32 characters long, with a maximum length of 256 characters.

Separate Content Management and Content Delivery Servers

To enhance security as part of a defense-in-depth strategy, it's crucial to minimize the exposure of your deployment.

Sitecore advises deploying distinct servers for Content Management (internal use only) and Content Delivery (public-facing) in a production environment. Your Content Management server should not be accessible from the internet.

If it is necessary to expose your Content Management server to the internet, you should:

• Use HTTPS to encrypt communications with the Content Management server.

• Implement IP Filtering to restrict access to a whitelist of approved clients.

Enforce a Strong Password Policy

Sitecore utilizes the Microsoft ASP.NET Membership Provider for user management by default. It is advisable to customize the password policy to align with your organization's security requirements.

In the web.config file, within the <membership> section, you can configure the following properties to enforce a robust password policy:

• minRequiredPasswordLength

• minRequiredNonAlphanumericCharacters

• maxInvalidPasswordAttempts

• passwordAttemptWindow

• passwordStrengthRegularExpression

Protect Connection String Passwords from Unauthorized Access

Sitecore stores connection string passwords in the App_Config\ConnectionStrings.config file. To prevent unauthorized access to these passwords, it is advisable to encrypt this file.

For securing connection strings in PaaS deployments using Kudu:

1. Navigate to App Service, then Development Tools, and click on Advanced Tools.

2. Open Kudu.

3. Click on Debug console, select Powershell, and navigate to site/wwwroot/App_config. Open the ConnectionStrings.config file.

4. In the ConnectionStrings.config file, remove the values for the database connection strings and save the changes. For instance, remove the values for core, master, security, and web.

5. Go back to App Service and navigate to Settings, then Configuration. In the Connection strings section, click New connection string. Add the connection strings for all the databases you need and click OK.

6. Click Save to apply the changes.

Updates and Disaster Recovery

We recommend using the latest version of Microsoft Windows supported by Sitecore and ensuring that your system remains updated with the latest security patches. Utilize the Windows Update/Automatic Update service to keep your systems current.

Additionally, we advise developing a comprehensive disaster recovery plan that includes:

• A strategy for obtaining new or temporary equipment.

• Procedures for restoring backups.

• Regular testing of the recovery plan.

Conclusion

Securing your Sitecore environment requires a comprehensive approach that encompasses application security, data protection, and infrastructure security. By following the best practices and strategies outlined in this article, you can ensure that your Sitecore deployment is secure and resilient against potential threats.

By following the detailed guidelines and implementing the solutions provided in this article, you will be well-equipped to secure your Sitecore environment and protect your digital assets from potential threats.