Azure Logic Apps is a cool cloud tool where you can create and run automated tasks with no code or with some code in JavaScript (not all functionallities of JavaScript are supported).

When working on a Logic App, it is often the case that sensitive data is used for testing during development. This could be e.g., the login and password to a test server. It is important that such data is not leaked, even if it is test data only. We don’t need to help an attacker to goes on the right track. 😉

Use secure inputs/outpus in actions

For example, we have a workflow that operates on sensitive data (Compose action concats variable with some string) (Figure 1).

Figure 1 – Example Azure Logic App

To secure data, Microsoft has introduced useful features called Secure Inputs and Secure Outputs. They can be changed in settings of the specific action. In that case, we have only one option: to secure inputs (Figure 2). This is very important when for example we have action to grab some secrets from Azure Key Vault.

Figure 2 – Secure inputs in designer

If we are developing directly in an ARM template JSON, then relevant section should be provided in a workflow code called runtimeConfiguration with secureData.

    "runtimeConfiguration": {
        "secureData": {
            "properties": [
            "inputs",
            "outputs"
            ]
        }
    }

Prevent hardcoded sensitive values in ARM templates

After running the action prepared in this way, we see that no one have access to data inputs and outputs in the logs (Figure 3).

Figure 3 – Logic App secured input and output

However, sometimes happens that a programmer tests the input data at the very beginning of development without securing it. All Logic App runs are stored in the Run History tab. This includes the definition of the app and any inputs and outputs data of each action. As the result, other user can view logs and find sensitive informations (Figure 4 and Figure 5).

Figure 4 – Logic App runs

Figure 5 – Logic App not secured input and output

The last place to verify is the `Deployments` section of a resource, where sensitive data could be placed directly into a JSON template during e.g., pipeline deployment process (Figure 7).

Figure 6 – Deployments section in RG

Be aware of version snapshots

Another place where developer may forget to prevent sensitive data leak is the `Versions` section, where snapshots of our application are captured and stored after each modification. Basically, it is a history of all previous definitions and there is no possibility to remove a specific version (Figure 6).

Figure 7 – Logic App versions

Reference:
https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-overview
https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-securing-a-logic-app?tabs=azure-portal

Author

Leave a Reply

Your email address will not be published. Required fields are marked *