GitHub Action risky pull_request_target usage¶
Checks for GitHub Action workflow using pull_request_target where the code from the incoming PR is checked out.
This is risky if you end up executing arbitrary code from the incoming PR as an attacker could steal repository secrets.
As stated in GitHub's documentation,
because it is inherently risky to run workflows on pull requests coming from forks, the standard pull_request workflow event disallows GitHub API write permissions and access to secrets owned by the target repository.
Nevertheless, in some rare cases one may need this kind of higher privilege access. This is where pull_request_target event comes in handy, but exposes secrets and gives a lot of power to authors of the inbound pull request.
A Continuous Integration (CI) system, such as GitHub Action, should be designed and configured as securely as production systems. In fact, since built artifacts coming out of such system are often deployed automatically (CD / Continuous Deployment) any compromise of CI/CD will indirectly affect production as malicious code can end up in production.
Examples¶
Insecure Example
on:
pull_request_target:
jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
ref: ${{ github.event.pull_request.head.sha }}
- uses: actions/setup-node@v1
- run: |
npm install
npm build
- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}
- uses: fakerepo/comment-on-pr@v1
with:
message: |
Thank you!
Secure Example
on:
pull_request_target:
types: [labeled]
jobs:
build:
name: Build and test
runs-on: ubuntu-latest
if: contains(github.event.pull_request.labels.*.name, 'safe to test')
steps:
- uses: actions/checkout@v2
with:
ref: ${{ github.event.pull_request.head.sha }}
- uses: actions/setup-node@v1
- run: |
npm install
npm build