Sitecore PowerShell Extensions (SPE) is a very sharp tool that allows you to execute  arbitrary code within your Sitecore instance and manipulate large amounts of content, all while providing a rich user interfaces for it. SPE frees you from the burden of having to restart the environment when deploying the code.

The great capabilities come with some risks you might not immediately realize:

It allows you to Execute Arbitrary code!

As appealing it may be for you, it might be even more appealing for malicious actors that seek taking over your environment. This is why we have introduced the concept of Session State Elevation in SPE 4.3.

Why introduce session state elevation?

The concept actually sounds like more than it is. “SPE elevated rights” means that SPE has put a named token in your session state that has an expiration time. We are not elevating anything related to any other aspect of your Sitecore environment – you’re “SPE elevated” which means we allow you to do execute Script and save it within your Sitecore environment.

How does PowerShell script get executed within my system?

Your PowerShell scripts can be introduced into the system a number of ways. The most prominent ones are:

• ISE – Writing scripts in this Sitecore app  is probably the most popular way you will provide the code for your authors. ISE allows you to write SPE Modules and Apps utilizing its full power of creating user interfaces, reports and dialogs.
• Console – This app is a decent entry point when you need to quickly provide a one liner to test something or just change a field in a large number of items.
• Saved Scripts – SPE allows you to save scripts as Sitecore items that can then be utilized by a number of “Integration Points”. By saving your script in a proper location (we use convention for determining which script is available in which integration point) you can expose your scripts in various places in Sitecore user interface, such as Content Editor context menu, Ribbon or even use them in workflow actions.
• Remoting – this allows you to execute a script by sending it to a web service.

Up until 4.2 it was enough that you log into your environment and had sufficient rights to open ISE or Console to be able to immediately execute your own scripts. While we’ve added role verifications to our endpoints, we were still a bit uneasy about just allowing the web services to hang in there waiting for the scripts while your session lasted. This meant that anyone could approach your computer and start executing code in your environment. It also meant that any script executed in your session would have your full user rights.

Should a mallicious actor be able to get a script onto your page (Sanitize your inputs!) they would be able to execute a script as you would. This is why we’ve introduces the concept of Session Elevation.

Where will I encounter Session State Elevation Requests?

You will run into Session State Elevation requests in ISE, Console, and when trying to view and save scripts in Content Editor, as well as when saving scripts in ISE.

What does it take to execute a script in ISE now?

As shown on the screenshot above you need to provide your credentials to execute your script. This elevates your session to have temporary execution rights.

While your session is elevated, we will not ask you for your password any longer. By default your session elevation token will expire after 5 minutes but you can change in a config file if you need to increase it.

Similarly we will ask you for elevation when you first start the SPE Console.

Another way someone can introduce a script within your system in through Content Editor by simply saving a script within one of the integration points. To mitigate that we have introduced Session Elevation concept on the save level. If you’re trying to Save a script or Script library without your session being elevated for save, we will reject the operation.

We will also not allow for showing scripts In Content Editor or modifying them there unless you elevate your session state to allow saving.

You can Elevate your session Saving privileges through the Content Editor Warning Action:

Now you can see and edit scripts in Content Editor and ISE:

What about remoting?

While Remoting sounds like the most dangerous (you send scripts to your server) it does require you to send your credentials every time which verifies your identity, which is what the Session Elevation attempts to do, so it is not needed there.

How can I configure Session State Elevation?

For the purpose of Session State Elevation configuration we have introduced a new section in our web.config include file defined as:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <powershell>
      <userAccountControl>
        <gates>
          <!--
            Gates into the system
            Ways ARBITRARY (not already saved/existing in the system) scripts might make into the system without explicitly providing password during the execution or save.
            Those gates require that the user session needs to be elevated with a proper token.
            Tokens are defined in the sestion below. Once Gate is elevated with a token it can do its job until token is dropped or expires.
            -->
          <gate name="Console" token="Console"/>
          <gate name="ISE" token="ISE"/>
          <gate name="ItemSave" token="ItemSave"/>
        </gates>
        <tokens>
          <!-- 
            Tokens provide means of elevation of the user session. Token can be used by one or more gates. 
            E.g. You can use the same token for all gates.
              elevationAction
                Token elavation actions:
                  - Block - always block action
                  - Password - Ask for Password to elevate session
                  - Allow - Always allow to elevate session without asking
              expiration
                TimeSpan serialized for how long session should stay elevated.
          -->
          <token name="Default" expiration="00:00:00" elevationAction="Block"/>
          <token name="Console" expiration="00:05:00" elevationAction="Password"/>
          <token name="ISE" expiration="00:05:00" elevationAction="Password"/>
          <token name="ItemSave" expiration="00:05:00" elevationAction="Password"/> 
        </tokens>
      </userAccountControl>
    </powershell>
  </sitecore>
</configuration>

Within the section you need to understand what a gate and what a token is.

Gate is a way scripts can make it to a system. That is the aforementioned ISE, Console and Items saved through Content Editor and otherwise. We define 3 gates in the platform and adding more will take no effect. Within the gate you can select which token will it use.

Token is the bit placed in your session that can expire or stay there as long as you need. You can define as many or as little tokens as you need. You can make all gates use the same token – in which case when you enable Session elevation for Execution in ISE, you will immediately gain access to script Saving as well and vice versa.

Token can specify that the gate will be protected with the password question if you set the elevationAction to “Password”, always open by setting it to “Allow” or never allow any scripts through the gate by setting the property to “Block”. Using the “Allow” value pretty much reverts SPE to the behaviour from before 4.3 when this functionality was implemented disabling the User Account Control.

While disabling User Account Control is acceptable on developer’s machine, it should NEVER be done on production!

I hope this article helps you understand why we introduced the concept and why it is important for the security of your environment as well as how to configure it.

Happy scripting!