Sitecore Security - Beyond the hardening guide

As with any publicly (or internally) accessible web application, it is vitally important to make sure that your Sitecore installation is appropriately configured to protect it against attacks from malicious forces on the net.

The primary reference to follow when configuring the security of your Sitecore instance is of course the Sitecore Security Hardening Guide.  However there are a few additional steps that you should consider following when configuring Sitecore to provide additional security against some known attack vectors where your Sitecore installation may be vulnerable.  All the recommendations and issues listed below appear to still be valid as of Sitecore v7.1

Extra restrictions on the /sitecore folder on delivery servers

The Hardening Guide recommends restricting Anonymous user access to the /sitecore/admin, /sitecore/debug and /sitecore/shell/WebService folders.  

My recommendation on delivery server instances is to go further and restrict anonymous access to all parts of the /sitecore folder apart from /sitecore/service.  This protects against other known and potentially unknown attack vectors within the Sitecore folder files.  One example I have seen documented is a insecure direct object reference attack which can allow a complete server compromise.  Restricting anonymous access to the /sitecore folder protects against this.

Dan McGuane from Sitecore Australia has pointed out to me that Sitecore does use the following path if you attempt to display a content item outside of a site root, which depending on how you structure content on your site may be impacted by this change (the user would get a 401 error): /Sitecore/content/globals/{item name} -- however this is not something that we would generally do in a Sitecore implementation.

Note when exposing the Sitecore Item Web API to external users you may also need to allow some additional anonymous user access, however you should very carefully read the associated documentation to understand how to configure it's specific security settings.

Disable XmlControls on delivery servers

Another potential vulnerability which can affect Sitecore installations is an XSS vulnerability which could allow an attacked to insert content such as iFrames into URLs being served by Sitecore.  This opens the possibility of an attacker directing a user to a URL on your site, but actually serving their site instead, which could obviously be a serious issue.

The attack is based on Sitecore's XmlControls functionality, although these are used in some parts of the Sitecore shell, this vector can easily be closed by an additional Sitecore configuration step in public facing sites.  In the <sites> section of Sitecore configuration,  include the attribute disableXmlControls="true" for each publicly accessible site.

Never make your Management server publicly accessible

This recommendation is really related to the two issues listed above, but I always in the strongest possible terms recommend to people not to allow public access to the Sitecore management server (yes, including having a single all-in-one Sitecore server acting as both management and delivery roles).  The management server is designed to allow access for people to manage content and does not appear to be sufficiently secure.

Instead, restrict access to this server to only a set of known good IP addresses via a firewall, establish a secure VPN bridge from your internal network into the hosting environment where you management server resides, or consider hosting the authoring server on your enterprise's internal network.

Don't Panic

I don't want this article to come across as saying that Sitecore isn't a secure system, however like every other system it needs to be properly configured to minimise security risks.

I believe the above steps that aren't yet documented in Sitecore's security documentation will make your installation even more secure, and I'm happy to report that our Sitecore installations have passed multiple external penetration tests with flying colours!