Translated ['src/binary-exploitation/rop-return-oriented-programing/srop

src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md

@@ -103,7 +103,7 @@ payload += bytes(frame)
 p.sendline(payload)
 p.interactive()
 ```
-## esempio di bof senza sigreturn
+## bof esempio senza sigreturn
 
 ### Codice
 ```c
@@ -209,13 +209,13 @@ Dopo aver inviato il frame, puoi inviare un secondo stadio contenente codice she
 
 ## Validazione del kernel, PAC e Shadow-Stacks
 
-Linux 5.16 ha introdotto una validazione più rigorosa dei frame dei segnali nello spazio utente (commit `36f5a6c73096`).  Il kernel ora controlla:
+Linux 5.16 ha introdotto una validazione più rigorosa dei frame di segnale dello spazio utente (commit `36f5a6c73096`).  Il kernel ora controlla:
 
 * `uc_flags` deve contenere `UC_FP_XSTATE` quando `extra_context` è presente.
 * La parola riservata in `struct rt_sigframe` deve essere zero.
 * Ogni puntatore nel record *extra_context* è allineato e punta all'interno dello spazio degli indirizzi utente.
 
-`pwntools>=4.10` crea automaticamente frame conformi, ma se li costruisci manualmente assicurati di inizializzare a zero *riservato* e di omettere il record SVE a meno che tu non ne abbia davvero bisogno; altrimenti `rt_sigreturn` restituirà `SIGSEGV` invece di tornare.
+`pwntools>=4.10` crea automaticamente frame conformi, ma se li costruisci manualmente assicurati di inizializzare a zero *reserved* e omettere il record SVE a meno che tu non ne abbia davvero bisogno; altrimenti `rt_sigreturn` restituirà `SIGSEGV` invece di tornare.
 
 A partire da Android 14 e Fedora 38, il userland è compilato con **PAC** (*Pointer Authentication*) e **BTI** abilitati per impostazione predefinita (`-mbranch-protection=standard`).  *SROP* stesso non è influenzato perché il kernel sovrascrive `PC` direttamente dal frame creato, bypassando l'LR autenticato salvato nello stack; tuttavia, qualsiasi **catena ROP successiva** che esegue salti indiretti deve saltare a istruzioni abilitate BTI o indirizzi PACed.  Tieni presente questo quando scegli i gadget.
 
@@ -223,7 +223,7 @@ Gli Shadow-Call-Stacks introdotti in ARMv8.9 (e già abilitati su ChromeOS 1.27+
 
 ## Riferimenti
 
-* [Documentazione sulla gestione dei segnali arm64 di Linux](https://docs.kernel.org/arch/arm64/signal.html)
+* [Documentazione sulla gestione dei segnali di Linux arm64](https://docs.kernel.org/arch/arm64/signal.html)
 * [LWN – "La protezione dei rami AArch64 arriva a GCC e glibc" (2023)](https://lwn.net/Articles/915041/)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md

@@ -51,7 +51,7 @@ Nota come if4 è considerato avere origine `null`.
 ### Iframes con CSP <a href="#iframes_with_csp_40" id="iframes_with_csp_40"></a>
 
 > [!TIP]
-> Si prega di notare come nei seguenti bypass la risposta alla pagina iframed non contenga alcun header CSP che impedisca l'esecuzione di JS.
+> Si prega di notare come nei seguenti bypass la risposta alla pagina incapsulata non contenga alcun header CSP che impedisca l'esecuzione di JS.
 
 Il valore `self` di `script-src` non permetterà l'esecuzione del codice JS utilizzando il protocollo `data:` o l'attributo `srcdoc`.\
 Tuttavia, anche il valore `none` della CSP permetterà l'esecuzione degli iframe che mettono un URL (completo o solo il percorso) nell'attributo `src`.\
@@ -179,7 +179,7 @@ Come spiegato in [questo articolo](https://blog.slonser.info/posts/make-self-xss
 
 Poiché **Chrome 110 (febbraio 2023) la funzionalità è abilitata per impostazione predefinita** e la specifica è in fase di standardizzazione tra i browser con il nome *anonymous iframe*. MDN la descrive come: “un meccanismo per caricare iframe di terze parti in una nuova partizione di archiviazione effimera in modo che nessun cookie, localStorage o IndexedDB venga condiviso con la vera origine”. Conseguenze per attaccanti e difensori:
 
-* Gli script in diversi iframe senza credenziali **condividono ancora la stessa origine di livello superiore** e possono interagire liberamente tramite il DOM, rendendo fattibili attacchi multi-iframe self-XSS (vedi PoC sotto).
+* Gli script in diversi iframe senza credenziali **condividono ancora la stessa origine di livello superiore** e possono interagire liberamente tramite il DOM, rendendo fattibili attacchi multi-iframe self-XSS (vedi PoC qui sotto).
 * Poiché la rete è **senza credenziali**, qualsiasi richiesta all'interno dell'iframe si comporta effettivamente come una sessione non autenticata – gli endpoint protetti da CSRF di solito falliscono, ma le pagine pubbliche vulnerabili tramite DOM sono ancora nel campo di applicazione.
 * I pop-up generati da un iframe senza credenziali ottengono un `rel="noopener"` implicito, interrompendo alcuni flussi OAuth.
 ```javascript
@@ -189,7 +189,7 @@ alert(window.top[2].document.cookie);                 // read -> foo=bar
 ```
 - Esempio di exploit: Self-XSS + CSRF
 
-In questo attacco, l'attaccante prepara una pagina web malevola con 2 iframes:
+In questo attacco, l'attaccante prepara una pagina web malevola con 2 iframe:
 
 - Un iframe che carica la pagina della vittima con il flag `credentialless` con un CSRF che attiva un XSS (Immagina un Self-XSS nel nome utente dell'utente):
 ```html
@@ -215,7 +215,7 @@ alert(window.top[1].document.cookie);
 ```
 ### fetchLater Attacco
 
-Come indicato in [questo articolo](https://blog.slonser.info/posts/make-self-xss-great-again/), l'API `fetchLater` consente di configurare una richiesta da eseguire in un secondo momento (dopo un certo tempo). Pertanto, questo può essere abusato per esempio, per effettuare il login di una vittima all'interno di una sessione dell'attaccante (con Self-XSS), impostare una richiesta `fetchLater` (per cambiare la password dell'utente corrente, ad esempio) e disconnettersi dalla sessione dell'attaccante. Poi, la vittima effettua il login nella propria sessione e la richiesta `fetchLater` verrà eseguita, cambiando la password della vittima in quella impostata dall'attaccante.
+Come indicato in [questo articolo](https://blog.slonser.info/posts/make-self-xss-great-again/), l'API `fetchLater` consente di configurare una richiesta da eseguire in un secondo momento (dopo un certo tempo). Pertanto, questo può essere abusato per, ad esempio, effettuare il login di una vittima all'interno di una sessione dell'attaccante (con Self-XSS), impostare una richiesta `fetchLater` (per cambiare la password dell'utente corrente, ad esempio) e disconnettersi dalla sessione dell'attaccante. Poi, la vittima effettua il login nella propria sessione e la richiesta `fetchLater` verrà eseguita, cambiando la password della vittima in quella impostata dall'attaccante.
 
 In questo modo, anche se l'URL della vittima non può essere caricato in un iframe (a causa di CSP o altre restrizioni), l'attaccante può comunque eseguire una richiesta nella sessione della vittima.
 ```javascript