Harden Security for your Sitecore Client Applications

tl;dr; Ensure you include an Assert.CanRunApplication(“/path-to-application”) check in your custom application to enforce security

Have you created any customs application in Sitecore? Do you use Sitecore Roles to restrict access to those applications?

Often only certain roles should have access to certain pieces of functionality, which is fairly standard requirement, and a common way to restrict access to applications is to remove Read access to the item in the Core Database.

Take for example default out of the box Sitecore applications such as the Indexing Manager. Your average author really should not have access to this more developer centric functionality. And if they did, then nothing too bad could happen, they’d just be able to kick off the re-indexing process. Nothing too bad, but it would be both unexpected and use up server resources for no particular reason.

But what if your custom application allowed you to update config file settings? If an unauthorized user made changes, as soon as the application modified the config file it would cause Sitecore to recycle the app pool. Again performance issues, your authors possibly losing work and any incorrect settings may cause your application (or part of it) to stop working.

What if your application gave access to enhanced functionality that allowed you to run all manner of commands across your content, databases or file system and manipulate them at will? You definitely want to only grant permissions to this to a very specific set of users.

Following a security audit of our application, one of the areas of concern raised was exactly as above. For example, if we have a user who is part of the Client Authoring role then the dashboard, menu and control panel all correctly restrict the applications that a user is able to see:

However, if a user knew the URL to the application and they were logged into the CMS, then they could access these applications directly, even though the applications may not appear in the menus or control panel since Read access was restricted.

Affected Applications

We carried out some further investigations and found the following applications were affected. Keep in mind in is not an exhaustive list:

  • /sitecore/shell/default.aspx?xmlcontrol=Database.Usage
  • /sitecore/shell/default.aspx?xmlcontrol=Databases.CleanUp
  • /sitecore/shell/default.aspx?xmlcontrol=IndexingManager
  • /sitecore/shell/default.aspx?xmlcontrol=SolrSchemaBuilder
  • /sitecore/shell/default.aspx?xmlcontrol=TransferToDatabase
  • /sitecore/shell/default.aspx?xmlcontrol=IDE.XPath.Builder
  • /sitecore/shell/Applications/PowerShell/PowerShellIse?sc_bw=1 [Sitecore PowerShell Extensions]
  • /sitecore/shell/default.aspx?xmlcontrol=CoveoConfigurationDialog [Coveo for Sitecore]
  • /sitecore/shell/default.aspx?xmlcontrol=CoveoTopResultsSynchronizationWizard

Some of the functionality is harmless, some could have more damaging effect. In any case, the permissions set should be respected since it is what the developer expected. Just to be clear, the user needs to have log in access to the CMS in some capacity, even as a basic user with the lowest login rights possible.

Fix for issue

The fix is remarkably simple, ensure you add the following code in the OnLoad method:

using Sitecore.Diagnostics;
Assert.CanRunApplication("/sitecore/content/Applications/Control Panel/Indexing/Indexing Manager");
// or whatever the path to your application is...

The code checks the security that has been set against the shortcut, and if the current user is not authorized then an exception is thrown that “Application access denied”

In fact, one of the (now hidden) applications already has the code present to deny access correctly: FileExplorer which can be accessed via /sitecore/shell/default.aspx?xmlcontrol=FileExplorer.

The code in FileExplorerForm.cs includes an Assert.CanRunApplication("Files/FileExplorer") check in the OnLoad method. This in turn checks if the user has read access to the item under ‘/sitecore/content/Applications/’ in Core DB. The code that is ultimately called is:

namespace Sitecore.Security
{
  public class SecurityHelper
  {
    public static bool CanRunApplication(string applicationName)
    {
      Assert.IsNotNullOrEmpty(applicationName, "applicationName");
      if (!applicationName.StartsWith("/", StringComparison.InvariantCulture))
        applicationName = "/sitecore/content/Applications/" + applicationName;
      Item obj = (Item) null;
      using (new SecurityDisabler())
        obj = Client.CoreDatabase.GetItem(applicationName);
      if (obj == null)
        return false;
      return obj.Access.CanRead();
    }
  }
}

Bug Reports:

The following bug reports were filed highlighting the issue and the fix required to resolve the issue:

Sitecore PowerShell Extensions
Reported: 25 November 2015
Fixed: 29 November 2015
Fix Version: v4.0

Coveo
Reported: 25 November 2015
Fixed: 24 March 2016
Ticket: 00028848
Fix Version: March 2016 Release

Sitecore
Reported: 2 December 2015 (via MVP channel on Sitecore Community forums – had no access to Support at the time)
Support Ticket Raised by Martina: 11 February 2016
Support Contacted: 7 April 2016
Resolved: 8 April 2016 (support replied to ticket as closed, ref #100267)
Fix Version: May 20, 2016 – released Sitecore 8.1 Update-3 (rev. 160519)

!IMPORTANT

If you have a custom application in your own project, maybe you have created a module on the Sitecore Marketplace or shared code through a shared source project then I highly recommend you review the code to ensure that the relevant code is in place which ensures that applications can only be run by authorized users.

If you are still running an earlier version of any of the modules listed above then you may wish to upgrade to the latest version.

Apologies for not blogging this out much much earlier. In the wait for all the fixes to be implemented, this totally fell by the wayside and I only just came back across my notes for the original tickets which I raised.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s