Code of Conduct

• I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?

Article: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions
that relates to https://docs.github.com/en/actions/creating-actions/creating-a-composite-action

What part(s) of the article would you like to see updated?

This issue is explicitly related to the Understanding the risk of script injections.

This section explains how command injection vulnerabilities could be exploited in GitHub actions and about untrusted inputs that users should avoid in inline scripts.

This section is followed by Good practices for mitigating script injection attacks.

The first good practice suggests creating a github composite action and passing untrusted arguments to the composite action.

uses: fakeaction/checktitle@v3
with:
    title: ${{ github.event.pull_request.title }}

It is described as follows: "This approach is not vulnerable to the injection attack, as the context value is not used to generate a shell script, but is passed to the action as an argument."

This statement is incorrect and may lead to different command injection attacks.
When creating a composite action, we specify some inputs and may specify outputs.

If those inputs are passed to an inline script, they will be vulnerable to command injection.
Let's start with the following scenario.

1. We have a github workflow called a.yml that is being trigged on every issue_comment.
2. We want to verify that each user submits a comment with an approved prefix
3. We want to check what is the best way to do that, and we follow the GitHub Actions security hardening guidelines.
4. We create a composite action (action.yml) and pass the command body to it.

Now, Inside the composite action, we access the issue body as follows:

- name: Test Comment
   shell: bash
   run: ./check-issue.sh ${{ inputs.body }}

If we pass the issue body as follows:

uses: ./github/actions/check-title
with:
    body: ${{ github.event.comment.body }}

This composite action will be vulnerable to command injection.

In addition, the Creating an action metadata file suggests and encourages users to input variables directly to inline scripts that may compromise their build pipeline.

I think this problem should be fixed in a couple of layers.

1. Changing the Good practices for mitigating script injection attacks to use composite action with environment variables to make sure composite actions will not be vulnerable to injection using the input variables from untrusted sources
2. Changing the Creating an action metadata file that encourages users to directly pass inputs variables directly to an inline script.

Additional information

Examples:

Let's see with a little example how such a pipeline could be compromised and how users can protect themself against such attacks.

First, we have the workflow file we described:

And we also created the following composite action:

Issue that look like this: $(ls) will trigger that pipeline + composite action to result:

• The same attack will be possible when using without the double quotes in the run script; I choose to demonstrate with the echo double quotes because the exploitation is easier to understand.

As we can see, using the composite action + inputs has resulted in a command injection, so the first misleading part is, "This approach is not vulnerable to the injection attack."

Secondly, as we said, the Creating an action metadata file suggests users to pass directly inputs to inline scripts.

Solution

A solution can be implemented differently, but one is declaring an environment variable outside the composite action and passing the env var.

Example

Now, our workflow will look like this:

And the composite action output will look like this:

This should help users pass untrusted inputs to action and be sure the action is not compromising their pipeline.