How to remove sensitive data from code and access Workspace ONE API's more securely (part 1)

Organizations that use custom built tools to access API's can approach this in a variety of ways. It is not uncommon to find tools developed with sensitive data contained within the source code itself. PowerShell scripts are a great example of where we can find sensitive data leaking. These scripts come with the best of intentions, but can accidentally contain the keys to the kingdom. We’ll look at how I use a config.ini file to access a funny environment we’ll call https://Kauai.ryanpringnitz.com, but before we proceed, cue the mood boosting visuals...

Storing sensitive data in code makes it difficult to commit code to a source version control system Bitbucket, GitHub, TFS, etc), as it would be insecure. It can even be against company policy to store sensitive data this way. By storing the sensitive information in a config.ini file; you can more easily present the code in a screen sharing session (maybe in a sprint demo), or commit your code to remote a repository. 

Examples of sensitive data found in custom tools include, but are not limited to;

• Hostname
• FQDN 
• API Key
• Plain Text Credential
• Base64 Encoded Credential
• UNC File Share

Let's take a look at what is commonly seen in the code of a custom built tool, that could be more securely implemented:

To improve on this; we can create a config.ini file that our code references. This removes the sensitive information previously stored in the script itself, and stores it in a config.ini file.

So, what does the config.ini file look like?






The config.ini file needs to be tailored to your environment. For example; line 11 contains the URL that can respond to API calls. Line 16 contains the base64encoded credentials. Line 17 contains the API key with proper scope for the environment. Finally, line 28 references the path where files can be stored for logging. Note, due to regex and how backslashes are parsed; you will have to use two backslash instead 

Let's rewrite that PowerShell code used above, and see how we to remove this sensitive data from the script using the config.ini file. Line 7 and 8 are going to get the location of the config.ini file.


Line 8, we store the contents of the config.ini file in the $WS1Env variable. This variable is an object that can be used in the script. For example, the URL of the environment is no longer exposed in plain text in the script. We have hidden the base64 encoded credentials, API key, and log path. This is accomplished by replacing sensitive data in the code with data obtained in the objects properties (e.g. $WS1Env.UATapikey )

To further improve the script and how it communicates with remote REST Endpoints, on line 3 and 4, communication is forced to use the TLS 1.2 cipher suite. 

We can take this one step further, and apply ACL's to the config.ini file to restrict access to approved users only. For instance, you could remove read access to the config.ini file, then grant read access only to a service account. To further secure access to the config.ini file, the service account could be enrolled in a privileged access management product

Mahalo,
Ryan Pringnitz