Orchestrator Runbooks and PowerShell literals

-

This specific strategy hasn't had much field testing yet, so this is a proof-of-concept overview.

Our admin who runs System Center Orchestrator realized a logical flaw in a lot of Orchestrator PowerShell examples and templates.

Most examples show something like this:

# Set script parameters from runbook data bus and Orchestrator global variables
# Define any inputs here and then add to the $argsArray and script block parameters below 

$DataBusInput1 = "{Parameter 1 from Initialize Data}"
$DataBusInput2 = "{Global Variable 1}"

Taken from PowerShell & System Center Orchestrator - Best Practice Template - TechNet Articles - United States (English) - TechNet Wiki (microsoft.com)


What orchestrator runs that script; it performs inline concatenation of its variables into the PowerShell script and executes it.
Since double quotes in PowerShell represents and expandable string then any $ in the Orchestrator variables means that execution will try to interpret a PowerShell variable from the string.

This opens up the potential for 2 problems:

  • intentional injection - It would take a very precisely targeted, high knowledge attack... which does happen, but it's probably not the top risk for most companies.

  • unintentional injection - We can never count on external systems to sanitize their inputs for us. 
    This is the exact conversation from my Designing for Application Security is designing for Data Validation post.
    "No one's going to inject you like the AS/400 will."

So when a SharePoint form sent an unexpected $ it gave the admin a nasty surprise. He asked me to help test his solution, and to both of us it looks like a better choice.

$Title = @'
{Title from "Get Project SR"} 
'@


By going to a literal string he gains protection against accidental expansion of anything that looks like a PowerShell variable.
By going a step further and using a Here-String literal he gains protection against all types of special characters. (This even includes protection against the presence of '@ as long as it's not the beginning characters of a new line.)

It seems like an improvement, and he may consider making a general template for his runbook scripts like this:

<# Parameterization Section: #>

$paramTitle = @'
{Title from "Get Project SR"} 
'@

$paramDescription = @'
{Description from "Get Project SR"} 
'@



<# Parameter transformation Section: #>

$paramTitle = $paramTitle.replace(...)

The transformation section is an example of where I personally would handle any further manipulation of the inputs before getting into the core of the script.

Comments

Post a Comment

Popular posts from this blog

Default Browser - set url association with PowerShell

-
 Something that is helpful to know for complicated environments. Background: We have a legacy software that is in the process of being rewritten as a Blazor application, as we begin integrating these things together one need is to make sure that invoked urls do not open in Internet Explorer.  Policy and OU based controls are not available within the timeline we're looking at. However we have an advantage in the fact that we're already using a .ps1 script that prepares some environment needs before  the software executes. Other alternatives: A popular recommendation for handling this is to work within the DefaultAssociationsConfiguration structure. This is a good option, and is well covered in articles like this:  set-default-browser-to-microsoft-edge-using-powershell/ Why this solution: This solution fits a need where anything that may cause IE to be reset as default is handled promptly without requiring a logoff or restart to take effect.  Components: Registry ...
Read more

LINQ within a foreach()

-
  An example of how LINQ where clauses save steps. The where can occur right within the declaration of the foreach LAMBDA syntax: foreach (var person in people.Where(n => n.sex == "male")) { ... } Query Syntax: foreach (var person in from person in people where person.sex == "male" select person) { ... } Both syntaxes compile to the same code (Credit to  @YuvalItzchakov   https://stackoverflow.com/a/25412168 )
Read more

Rules of Automation

-
  Automation has several concrete rules: ·           Automation requires a system o      You can't automate an action, you can automate a process.   ·           The process has to be well defined o      All actions have to be expressible with valid conditional logic      ("If this, … and this, …but not this"). o      Ultimately this means you can't use the word "sometimes" in the process description. o      All needed condition values must be in a ready and readable state before the trigger is given for an automation step.   ·           Automation projects fail because of weak processes, not because of weak technology.
Read more