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:
Log in as an administrator:
Modify the configuration files:
Update the web.config file:
Update Sitecore Identity Server:
Restart the Identity Server:
Change the admin password:
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.
Update other user passwords:
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:
Navigate to the administrative tools folder.
Click on the tool you want to disable.
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:
Open the web.config file.
Locate the <httpHandlers> section (it may be called <Handlers> depending on your IIS pool).
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:
To disable the xslExtension helper:
In the App_Config/Include folder, create a patch file. Name the file with a .config extension.
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:
Enable SSL: Make the login page accessible only through SSL.
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.
Disable the "Remember me" checkbox: Remove the option for users to save their login credentials on the login page.
Steps to Implement:
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.
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.
Disable the "Remember Last Logged In User Name" setting:
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:
Open the web.config file with general Sitecore settings:
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.
Disable the web.config file with EXM settings:
Allow Unrestricted Access to a Specific File Path
After restricting general access, you might need to allow access to specific files.
Open the web.config file with general Sitecore settings.
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:
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.
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:
Example Configuration to Move PhantomJS:
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).
Create a Patch File:
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>
Move Contents from the App_Data Folder:
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:
Create a Patch File:
Insert the Configuration Code:
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<settings>
<setting
name="Media.RequestProtection.SharedSecret" value="YourRandomGeneratedString"/>
</settings>
</sitecore>
</configuration>
Save the Patch File:
Important Note:
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:
Open the <webroot>\Web.config file.
Locate the <authentication> node.
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:
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:
Open the web.config file.
Locate the <system.webServer><modules> section.
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:
In Non-Content Management Environments:
<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" />
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>
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:
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:
Navigate to App Service, then Development Tools, and click on Advanced Tools.
Open Kudu.
Click on Debug console, select Powershell, and navigate to site/wwwroot/App_config. Open the ConnectionStrings.config file.
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.
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.
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.