mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 14:40:37 -08:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
@@ -24,7 +24,7 @@ Falls Sie den **Benutzer, das Repo oder die Organisation, die Sie anvisieren mö
|
||||
|
||||
### Github Dorks
|
||||
|
||||
Github ermöglicht es, **nach etwas zu suchen, indem man als Umfang einen Benutzer, ein Repo oder eine Organisation angibt**. Daher können Sie mit einer Liste von Zeichenfolgen, die in der Nähe sensibler Informationen erscheinen, leicht **nach potenziell sensiblen Informationen in Ihrem Ziel suchen**.
|
||||
Github ermöglicht es, **nach etwas zu suchen, indem man als Bereich einen Benutzer, ein Repo oder eine Organisation angibt**. Daher können Sie mit einer Liste von Zeichenfolgen, die in der Nähe sensibler Informationen erscheinen, leicht **nach potenziell sensiblen Informationen in Ihrem Ziel suchen**.
|
||||
|
||||
Tools (jedes Tool enthält seine Liste von Dorks):
|
||||
|
||||
@@ -32,9 +32,9 @@ Tools (jedes Tool enthält seine Liste von Dorks):
|
||||
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks-Liste](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
|
||||
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Dorks-Liste](https://github.com/hisxo/gitGraber/tree/master/wordlists))
|
||||
|
||||
### Github-Leaks
|
||||
### Github Leaks
|
||||
|
||||
Bitte beachten Sie, dass die Github-Dorks auch dazu gedacht sind, nach Leaks zu suchen, indem die Suchoptionen von Github verwendet werden. Dieser Abschnitt ist den Tools gewidmet, die **jedes Repo herunterladen und nach sensiblen Informationen darin suchen** (sogar bestimmte Tiefen von Commits überprüfen).
|
||||
Bitte beachten Sie, dass die Github Dorks auch dazu gedacht sind, nach Leaks zu suchen, indem die Suchoptionen von Github verwendet werden. Dieser Abschnitt ist den Tools gewidmet, die **jedes Repo herunterladen und nach sensiblen Informationen darin suchen** (sogar bestimmte Tiefen von Commits überprüfen).
|
||||
|
||||
Tools (jedes Tool enthält seine Liste von Regex):
|
||||
|
||||
@@ -53,7 +53,7 @@ Tools (jedes Tool enthält seine Liste von Regex):
|
||||
|
||||
Es ist möglich, **Repos zu kompromittieren, indem man Pull-Requests missbraucht**. Um zu wissen, ob ein Repo anfällig ist, müssen Sie hauptsächlich die Github Actions YAML-Konfigurationen lesen. [**Weitere Informationen dazu finden Sie unten**](./#execution-from-a-external-fork).
|
||||
|
||||
### Github-Leaks in gelöschten/internen Forks
|
||||
### Github Leaks in gelöschten/internen Forks
|
||||
|
||||
Selbst wenn sie gelöscht oder intern sind, könnte es möglich sein, sensible Daten aus Forks von Github-Repositories zu erhalten. Überprüfen Sie es hier:
|
||||
|
||||
@@ -67,12 +67,12 @@ accessible-deleted-data-in-github.md
|
||||
|
||||
Es gibt einige **Standardprivilegien**, die Mitgliedern der Organisation zugewiesen werden können. Diese können von der Seite `https://github.com/organizations/<org_name>/settings/member_privileges` oder von der [**Organizations API**](https://docs.github.com/en/rest/orgs/orgs) gesteuert werden.
|
||||
|
||||
- **Basisberechtigungen**: Mitglieder haben die Berechtigung None/Read/write/Admin über die Repos der Organisation. Empfohlen ist **None** oder **Read**.
|
||||
- **Repository-Forking**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht zu erlauben**, Organisation-Repositories zu forken.
|
||||
- **Seiten erstellen**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht zu erlauben**, Seiten aus den Org-Repos zu veröffentlichen. Wenn nötig, können Sie das Erstellen öffentlicher oder privater Seiten erlauben.
|
||||
- **Basisberechtigungen**: Mitglieder haben die Berechtigung None/Read/write/Admin über die Repos der Organisation. Empfohlen wird **None** oder **Read**.
|
||||
- **Repository-Forking**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht** zu erlauben, Repositories der Organisation zu forken.
|
||||
- **Seiten erstellen**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht** zu erlauben, Seiten aus den Repos der Organisation zu veröffentlichen. Wenn notwendig, können Sie das Erstellen öffentlicher oder privater Seiten erlauben.
|
||||
- **Zugriffsanforderungen für Integrationen**: Mit dieser Aktivierung können externe Mitarbeiter den Zugriff auf GitHub oder OAuth-Apps anfordern, um auf diese Organisation und ihre Ressourcen zuzugreifen. Es ist normalerweise erforderlich, aber wenn nicht, ist es besser, es zu deaktivieren.
|
||||
- _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
|
||||
- **Änderung der Repository-Sichtbarkeit**: Wenn aktiviert, können **Mitglieder** mit **Admin**-Berechtigungen für das **Repository** die **Sichtbarkeit ändern**. Wenn deaktiviert, können nur Organisationsinhaber die Sichtbarkeit von Repositories ändern. Wenn Sie **nicht** möchten, dass Personen Dinge **öffentlich** machen, stellen Sie sicher, dass dies **deaktiviert** ist.
|
||||
- **Änderung der Repository-Sichtbarkeit**: Wenn aktiviert, können **Mitglieder** mit **Admin**-Berechtigungen für das **Repository** die **Sichtbarkeit ändern**. Wenn deaktiviert, können nur Organisationsinhaber die Sichtbarkeit von Repositories ändern. Wenn Sie nicht möchten, dass Personen Dinge **öffentlich** machen, stellen Sie sicher, dass dies **deaktiviert** ist.
|
||||
- _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
|
||||
- **Löschen und Übertragen von Repositories**: Wenn aktiviert, können Mitglieder mit **Admin**-Berechtigungen für das Repository **öffentliche und private Repositories löschen oder übertragen**.
|
||||
- _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
|
||||
@@ -105,11 +105,11 @@ _Lassen Sie es mich wissen, wenn Sie den API-Endpunkt kennen, um auf diese Infor
|
||||
|
||||
## Rekognoszierung & Angriffe unter Ausnutzung von Anmeldeinformationen
|
||||
|
||||
Für dieses Szenario nehmen wir an, dass Sie Zugang zu einem Github-Konto erhalten haben.
|
||||
Für dieses Szenario nehmen wir an, dass Sie Zugriff auf ein Github-Konto erhalten haben.
|
||||
|
||||
### Mit Benutzeranmeldeinformationen
|
||||
|
||||
Wenn Sie irgendwie bereits Anmeldeinformationen für einen Benutzer innerhalb einer Organisation haben, können Sie **einfach einloggen** und überprüfen, welche **Enterprise- und Organisationsrollen Sie haben**, ob Sie ein einfaches Mitglied sind, überprüfen, welche **Berechtigungen einfache Mitglieder haben**, in welchen **Gruppen** Sie sind, welche **Berechtigungen Sie haben** über welche **Repos** und **wie die Repos geschützt sind**.
|
||||
Wenn Sie irgendwie bereits Anmeldeinformationen für einen Benutzer innerhalb einer Organisation haben, können Sie **einfach einloggen** und überprüfen, welche **Unternehmens- und Organisationsrollen Sie haben**, wenn Sie ein einfaches Mitglied sind, überprüfen Sie, welche **Berechtigungen einfache Mitglieder haben**, in welchen **Gruppen** Sie sind, welche **Berechtigungen Sie haben** über welche **Repos** und **wie die Repos geschützt sind**.
|
||||
|
||||
Beachten Sie, dass **2FA verwendet werden kann**, sodass Sie diese Informationen nur abrufen können, wenn Sie auch **diesen Check bestehen**.
|
||||
|
||||
@@ -128,9 +128,9 @@ Mit diesem Schlüssel können Sie **Änderungen in Repositories vornehmen, in de
|
||||
# Get repo config and current user name and email
|
||||
git config --list
|
||||
```
|
||||
Wenn der Benutzer seinen Benutzernamen als seinen GitHub-Benutzernamen konfiguriert hat, können Sie auf die **öffentlichen Schlüssel, die er in seinem Konto festgelegt hat**, unter _https://github.com/\<github_username>.keys_ zugreifen. Sie könnten dies überprüfen, um zu bestätigen, dass der private Schlüssel, den Sie gefunden haben, verwendet werden kann.
|
||||
Wenn der Benutzer seinen Benutzernamen als seinen GitHub-Benutzernamen konfiguriert hat, können Sie auf die **öffentlichen Schlüssel, die er in seinem Konto festgelegt hat**, unter _https://github.com/\<github_username>.keys_ zugreifen. Sie könnten dies überprüfen, um zu bestätigen, dass der gefundene private Schlüssel verwendet werden kann.
|
||||
|
||||
**SSH-Schlüssel** können auch in Repositories als **Deploy-Schlüssel** festgelegt werden. Jeder, der Zugriff auf diesen Schlüssel hat, kann **Projekte aus einem Repository starten**. In einem Server mit verschiedenen Deploy-Schlüsseln gibt die lokale Datei **`~/.ssh/config`** Informationen darüber, welcher Schlüssel zugeordnet ist.
|
||||
**SSH-Schlüssel** können auch in Repositories als **Deploy-Schlüssel** festgelegt werden. Jeder, der Zugriff auf diesen Schlüssel hat, kann **Projekte aus einem Repository starten**. In der Regel gibt die lokale Datei **`~/.ssh/config`** auf einem Server mit verschiedenen Deploy-Schlüsseln Informationen darüber, welcher Schlüssel zugeordnet ist.
|
||||
|
||||
#### GPG-Schlüssel
|
||||
|
||||
@@ -144,7 +144,7 @@ gpg --list-secret-keys --keyid-format=long
|
||||
|
||||
Für eine Einführung über [**Benutzer-Token siehe die grundlegenden Informationen**](basic-github-information.md#personal-access-tokens).
|
||||
|
||||
Ein Benutzer-Token kann **anstatt eines Passworts** für Git über HTTPS verwendet werden oder kann verwendet werden, um sich [**über die Basis-Authentifizierung bei der API zu authentifizieren**](https://docs.github.com/v3/auth/#basic-authentication). Abhängig von den damit verbundenen Berechtigungen können Sie möglicherweise verschiedene Aktionen ausführen.
|
||||
Ein Benutzer-Token kann **anstelle eines Passworts** für Git über HTTPS verwendet werden oder kann verwendet werden, um sich [**über die Basis-Authentifizierung bei der API zu authentifizieren**](https://docs.github.com/v3/auth/#basic-authentication). Abhängig von den damit verbundenen Berechtigungen können Sie möglicherweise verschiedene Aktionen ausführen.
|
||||
|
||||
Ein Benutzer-Token sieht so aus: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
|
||||
|
||||
@@ -152,7 +152,7 @@ Ein Benutzer-Token sieht so aus: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
|
||||
|
||||
Für eine Einführung über [**Github Oauth-Anwendungen siehe die grundlegenden Informationen**](basic-github-information.md#oauth-applications).
|
||||
|
||||
Ein Angreifer könnte eine **bösartige Oauth-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich im Rahmen einer Phishing-Kampagne akzeptieren.
|
||||
Ein Angreifer könnte eine **bösartige Oauth-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich als Teil einer Phishing-Kampagne akzeptieren.
|
||||
|
||||
Dies sind die [Scopes, die eine Oauth-Anwendung anfordern kann](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). Man sollte immer die angeforderten Scopes überprüfen, bevor man sie akzeptiert.
|
||||
|
||||
@@ -162,13 +162,13 @@ Darüber hinaus können, wie in den grundlegenden Informationen erklärt, **Orga
|
||||
|
||||
Für eine Einführung über [**Github-Anwendungen siehe die grundlegenden Informationen**](basic-github-information.md#github-applications).
|
||||
|
||||
Ein Angreifer könnte eine **bösartige Github-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich im Rahmen einer Phishing-Kampagne akzeptieren.
|
||||
Ein Angreifer könnte eine **bösartige Github-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich als Teil einer Phishing-Kampagne akzeptieren.
|
||||
|
||||
Darüber hinaus können, wie in den grundlegenden Informationen erklärt, **Organisationen den Zugriff auf Drittanbieteranwendungen** auf Informationen/Repos/Aktionen, die mit der Organisation verbunden sind, gewähren oder verweigern.
|
||||
|
||||
## Kompromittierung & Missbrauch von Github Action
|
||||
## Kompromittierung & Missbrauch von Github-Aktionen
|
||||
|
||||
Es gibt mehrere Techniken, um eine Github Action zu kompromittieren und zu missbrauchen, überprüfen Sie sie hier:
|
||||
Es gibt mehrere Techniken, um eine Github-Aktion zu kompromittieren und zu missbrauchen, überprüfen Sie sie hier:
|
||||
|
||||
{{#ref}}
|
||||
abusing-github-actions/
|
||||
@@ -176,25 +176,25 @@ abusing-github-actions/
|
||||
|
||||
## Umgehung des Branch-Schutzes
|
||||
|
||||
- **Erforderliche Anzahl von Genehmigungen**: Wenn Sie mehrere Konten kompromittiert haben, könnten Sie einfach Ihre PRs von anderen Konten akzeptieren. Wenn Sie nur das Konto haben, von dem Sie die PR erstellt haben, können Sie Ihre eigene PR nicht akzeptieren. Wenn Sie jedoch Zugriff auf eine **Github Action**-Umgebung im Repo haben, können Sie mit dem **GITHUB_TOKEN** möglicherweise Ihre PR **genehmigen** und auf diese Weise 1 Genehmigung erhalten.
|
||||
- _Hinweis für dies und für die Code-Eigentümer-Beschränkung, dass ein Benutzer normalerweise seine eigenen PRs nicht genehmigen kann, aber wenn Sie es können, können Sie es ausnutzen, um Ihre PRs zu akzeptieren._
|
||||
- **Genehmigungen zurückweisen, wenn neue Commits gepusht werden**: Wenn dies nicht festgelegt ist, können Sie legitimen Code einreichen, warten, bis jemand ihn genehmigt, und dann bösartigen Code hinzufügen und in den geschützten Branch zusammenführen.
|
||||
- **Überprüfungen von Code-Eigentümern anfordern**: Wenn dies aktiviert ist und Sie ein Code-Eigentümer sind, könnten Sie eine **Github Action erstellen, die Ihre PR erstellt und dann selbst genehmigt**.
|
||||
- Wenn eine **CODEOWNER-Datei falsch konfiguriert ist**, beschwert sich Github nicht, aber sie wird nicht verwendet. Daher, wenn sie falsch konfiguriert ist, wird **der Schutz der Code-Eigentümer nicht angewendet.**
|
||||
- **Erlauben Sie bestimmten Akteuren, die Anforderungen an Pull-Requests zu umgehen**: Wenn Sie einer dieser Akteure sind, können Sie die Pull-Request-Schutzmaßnahmen umgehen.
|
||||
- **Administratoren einbeziehen**: Wenn dies nicht festgelegt ist und Sie Administrator des Repos sind, können Sie diese Branch-Schutzmaßnahmen umgehen.
|
||||
- **Erfordere eine Anzahl von Genehmigungen**: Wenn Sie mehrere Konten kompromittiert haben, könnten Sie einfach Ihre PRs von anderen Konten akzeptieren. Wenn Sie nur das Konto haben, von dem Sie die PR erstellt haben, können Sie Ihre eigene PR nicht akzeptieren. Wenn Sie jedoch Zugriff auf eine **Github-Aktionsumgebung** im Repo haben, können Sie mit dem **GITHUB_TOKEN** möglicherweise Ihre PR **genehmigen** und auf diese Weise 1 Genehmigung erhalten.
|
||||
- _Hinweis für dies und für die Code-Eigentümer-Beschränkung, dass normalerweise ein Benutzer seine eigenen PRs nicht genehmigen kann, aber wenn Sie es können, können Sie es ausnutzen, um Ihre PRs zu akzeptieren._
|
||||
- **Genehmigungen zurückweisen, wenn neue Commits gepusht werden**: Wenn dies nicht eingestellt ist, können Sie legitimen Code einreichen, warten, bis jemand ihn genehmigt, und dann bösartigen Code hinzufügen und ihn in den geschützten Branch zusammenführen.
|
||||
- **Erfordere Überprüfungen von Code-Eigentümern**: Wenn dies aktiviert ist und Sie ein Code-Eigentümer sind, könnten Sie eine **Github-Aktion erstellen, die Ihre PR erstellt und dann selbst genehmigt**.
|
||||
- Wenn eine **CODEOWNER-Datei falsch konfiguriert ist**, beschwert sich Github nicht, aber es wird nicht verwendet. Daher, wenn sie falsch konfiguriert ist, wird **der Schutz der Code-Eigentümer nicht angewendet.**
|
||||
- **Erlaube bestimmten Akteuren, die Anforderungen an Pull-Requests zu umgehen**: Wenn Sie einer dieser Akteure sind, können Sie die Pull-Request-Schutzmaßnahmen umgehen.
|
||||
- **Administratoren einbeziehen**: Wenn dies nicht eingestellt ist und Sie Administrator des Repos sind, können Sie diese Branch-Schutzmaßnahmen umgehen.
|
||||
- **PR-Hijacking**: Sie könnten in der Lage sein, die **PR eines anderen zu ändern**, indem Sie bösartigen Code hinzufügen, die resultierende PR selbst genehmigen und alles zusammenführen.
|
||||
- **Entfernen von Branch-Schutzmaßnahmen**: Wenn Sie ein **Administrator des Repos sind, können Sie die Schutzmaßnahmen deaktivieren**, Ihre PR zusammenführen und die Schutzmaßnahmen wieder aktivieren.
|
||||
- **Umgehung von Push-Schutzmaßnahmen**: Wenn ein Repo **nur bestimmten Benutzern** erlaubt, Push (Code zusammenführen) in Branches zu senden (der Branch-Schutz könnte alle Branches schützen, indem das Wildcard `*` angegeben wird).
|
||||
- Wenn Sie **Schreibzugriff auf das Repo haben, aber nicht berechtigt sind, Code zu pushen** aufgrund des Branch-Schutzes, können Sie dennoch **einen neuen Branch erstellen** und darin eine **Github Action erstellen, die ausgelöst wird, wenn Code gepusht wird**. Da der **Branch-Schutz den Branch nicht schützt, bis er erstellt ist**, wird dieser erste Code-Push in den Branch die **Github Action ausführen**.
|
||||
- Wenn Sie **Schreibzugriff auf das Repo haben, aber nicht berechtigt sind, Code zu pushen** aufgrund des Branch-Schutzes, können Sie dennoch **einen neuen Branch erstellen** und darin eine **Github-Aktion erstellen, die ausgelöst wird, wenn Code gepusht wird**. Da der **Branch-Schutz den Branch nicht schützt, bis er erstellt ist**, wird dieser erste Code-Push in den Branch die **Github-Aktion ausführen**.
|
||||
|
||||
## Umgehung von Umgebungs-Schutzmaßnahmen
|
||||
|
||||
Für eine Einführung über [**Github-Umgebungen siehe die grundlegenden Informationen**](basic-github-information.md#git-environments).
|
||||
|
||||
Falls eine Umgebung von **allen Branches aus zugänglich ist**, ist sie **nicht geschützt** und Sie können leicht auf die Geheimnisse innerhalb der Umgebung zugreifen. Beachten Sie, dass Sie auf Repos stoßen könnten, in denen **alle Branches geschützt sind** (indem ihre Namen angegeben oder `*` verwendet wird). In diesem Szenario sollten Sie **einen Branch finden, in den Sie Code pushen können**, und Sie können die Geheimnisse exfiltrieren, indem Sie eine neue Github Action erstellen (oder eine vorhandene ändern).
|
||||
Falls eine Umgebung von **allen Branches aus zugänglich ist**, ist sie **nicht geschützt** und Sie können leicht auf die Geheimnisse innerhalb der Umgebung zugreifen. Beachten Sie, dass Sie möglicherweise Repos finden, in denen **alle Branches geschützt sind** (indem ihre Namen angegeben oder `*` verwendet wird). In diesem Szenario sollten Sie **einen Branch finden, in den Sie Code pushen können**, und Sie können die Geheimnisse exfiltrieren, indem Sie eine neue Github-Aktion erstellen (oder eine vorhandene ändern).
|
||||
|
||||
Beachten Sie, dass Sie auf den Grenzfall stoßen könnten, in dem **alle Branches geschützt sind** (über Wildcard `*`), es wird angegeben, **wer Code in die Branches pushen kann** (_das können Sie im Branch-Schutz angeben_) und **Ihr Benutzer nicht berechtigt ist**. Sie können dennoch eine benutzerdefinierte Github Action ausführen, da Sie einen Branch erstellen und den Push-Trigger über sich selbst verwenden können. Der **Branch-Schutz erlaubt den Push in einen neuen Branch, sodass die Github Action ausgelöst wird**.
|
||||
Beachten Sie, dass Sie möglicherweise den Grenzfall finden, in dem **alle Branches geschützt sind** (über Wildcard `*`), es wird angegeben, **wer Code in die Branches pushen kann** (_das können Sie im Branch-Schutz angeben_) und **Ihr Benutzer nicht berechtigt ist**. Sie können dennoch eine benutzerdefinierte Github-Aktion ausführen, da Sie einen Branch erstellen und den Push-Trigger über sich selbst verwenden können. Der **Branch-Schutz erlaubt den Push in einen neuen Branch, sodass die Github-Aktion ausgelöst wird**.
|
||||
```yaml
|
||||
push: # Run it when a push is made to a branch
|
||||
branches:
|
||||
@@ -206,8 +206,8 @@ Beachten Sie, dass **nach der Erstellung** des Branches der **Branch-Schutz auf
|
||||
|
||||
- Generieren Sie **Benutzertoken**
|
||||
- Stehlen Sie **Github-Tokens** aus **Secrets**
|
||||
- **Löschung** von Workflow-**Ergebnissen** und **Branches**
|
||||
- Gewähren Sie **mehr Berechtigungen für die gesamte Organisation**
|
||||
- **Löschen** von Workflow-**Ergebnissen** und **Branches**
|
||||
- Geben Sie **mehr Berechtigungen für die gesamte Organisation**
|
||||
- Erstellen Sie **Webhooks**, um Informationen zu exfiltrieren
|
||||
- Laden Sie **außenstehende Mitarbeiter** ein
|
||||
- **Entfernen** Sie **Webhooks**, die vom **SIEM** verwendet werden
|
||||
@@ -216,7 +216,7 @@ Beachten Sie, dass **nach der Erstellung** des Branches der **Branch-Schutz auf
|
||||
|
||||
### Imposter Commits - Hintertür über Repo-Commits
|
||||
|
||||
In Github ist es möglich, **einen PR zu einem Repo von einem Fork zu erstellen**. Selbst wenn der PR **nicht akzeptiert** wird, wird eine **Commit**-ID im ursprünglichen Repo für die Fork-Version des Codes erstellt. Daher könnte ein Angreifer **einen bestimmten Commit aus einem anscheinend legitimen Repo verwenden, das nicht vom Eigentümer des Repos erstellt wurde**.
|
||||
In Github ist es möglich, **einen PR zu einem Repo von einem Fork zu erstellen**. Selbst wenn der PR **nicht akzeptiert** wird, wird eine **Commit**-ID im ursprünglichen Repo für die Fork-Version des Codes erstellt. Daher könnte ein Angreifer **einen bestimmten Commit aus einem anscheinend legitimen Repo verwenden, der nicht vom Eigentümer des Repos erstellt wurde**.
|
||||
|
||||
Wie [**dies**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
|
||||
```yaml
|
||||
|
||||
Reference in New Issue
Block a user