Translated ['src/pentesting-web/domain-subdomain-takeover.md', 'src/pent

src/pentesting-web/domain-subdomain-takeover.md

@@ -5,7 +5,7 @@
 
 ## Domain takeover
 
-Se scopri un dominio (domain.tld) che **viene utilizzato da qualche servizio all'interno dell'ambito** ma la **società** ha **perso** la **proprietà** di esso, puoi provare a **registrarlo** (se abbastanza economico) e far sapere alla società. Se questo dominio sta ricevendo alcune **informazioni sensibili** come un cookie di sessione tramite **GET** parametro o nell'intestazione **Referer**, questa è sicuramente una **vulnerabilità**.
+Se scopri un dominio (domain.tld) che è **utilizzato da qualche servizio all'interno dell'ambito** ma che la **società** ha **perso** la **proprietà**, puoi provare a **registrarlo** (se abbastanza economico) e far sapere alla società. Se questo dominio sta ricevendo alcune **informazioni sensibili** come un cookie di sessione tramite **GET** parametro o nell'intestazione **Referer**, questa è sicuramente una **vulnerabilità**.
 
 ### Subdomain takeover
 
@@ -33,13 +33,13 @@ Quando viene utilizzato un wildcard DNS in un dominio, qualsiasi sottodominio ri
 
 Ad esempio, se `*.testing.com` è wildcard a `1.1.1.1`. Allora, `not-existent.testing.com` punterà a `1.1.1.1`.
 
-Tuttavia, se invece di puntare a un indirizzo IP, l'amministratore di sistema lo punta a un **servizio di terze parti tramite CNAME**, come un sottodominio G**ithub** per esempio (`sohomdatta1.github.io`). Un attaccante potrebbe **creare la propria pagina di terze parti** (in Gihub in questo caso) e dire che `something.testing.com` punta lì. Perché, il **CNAME wildcard** consentirà all'attaccante di **generare sottodomini arbitrari per il dominio della vittima che puntano alle sue pagine**.
+Tuttavia, se invece di puntare a un indirizzo IP, l'amministratore di sistema lo punta a un **servizio di terze parti tramite CNAME**, come un **sottodominio GitHub** per esempio (`sohomdatta1.github.io`). Un attaccante potrebbe **creare la propria pagina di terze parti** (in GitHub in questo caso) e dire che `something.testing.com` punta lì. Perché, il **CNAME wildcard** consentirà all'attaccante di **generare sottodomini arbitrari per il dominio della vittima che puntano alle sue pagine**.
 
 Puoi trovare un esempio di questa vulnerabilità nel write-up CTF: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
 
 ## Exploiting a subdomain takeover
 
-Il takeover del sottodominio è essenzialmente uno spoofing DNS per un dominio specifico su Internet, consentendo agli attaccanti di impostare record A per un dominio, portando i browser a visualizzare contenuti dal server dell'attaccante. Questa **trasparenza** nei browser rende i domini vulnerabili al phishing. Gli attaccanti possono impiegare [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) o [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) per questo scopo. Sono particolarmente vulnerabili i domini in cui l'URL in un'email di phishing appare legittimo, ingannando gli utenti ed eludendo i filtri antispam a causa della fiducia intrinseca del dominio.
+Il takeover del sottodominio è essenzialmente uno spoofing DNS per un dominio specifico su Internet, consentendo agli attaccanti di impostare record A per un dominio, portando i browser a visualizzare contenuti dal server dell'attaccante. Questa **trasparenza** nei browser rende i domini vulnerabili al phishing. Gli attaccanti possono impiegare [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) o [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) per questo scopo. Sono particolarmente vulnerabili i domini in cui l'URL in un'email di phishing appare legittimo, ingannando gli utenti e eludendo i filtri antispam a causa della fiducia intrinseca del dominio.
 
 Controlla questo [post per ulteriori dettagli](https://0xpatrik.com/subdomain-takeover/)
 
@@ -51,13 +51,29 @@ I certificati SSL, se generati dagli attaccanti tramite servizi come [_Let's Enc
 
 La trasparenza del browser si estende anche alla sicurezza dei cookie, governata da politiche come la [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy). I cookie, spesso utilizzati per gestire sessioni e memorizzare token di accesso, possono essere sfruttati attraverso il takeover del sottodominio. Gli attaccanti possono **raccogliere cookie di sessione** semplicemente indirizzando gli utenti a un sottodominio compromesso, mettendo a rischio i dati e la privacy degli utenti.
 
+### CORS Bypass
+
+Potrebbe essere possibile che ogni sottodominio sia autorizzato ad accedere alle risorse CORS dal dominio principale o da altri sottodomini. Questo potrebbe essere sfruttato da un attaccante per **accedere a informazioni sensibili** abusando delle richieste CORS.
+
+### CSRF - Same-Site Cookies bypass
+
+Potrebbe essere possibile che il sottodominio sia autorizzato a inviare cookie al dominio o ad altri sottodomini, cosa che è stata impedita dall'attributo `Same-Site` dei cookie. Tuttavia, nota che i token anti-CSRF impediranno comunque questo attacco se sono implementati correttamente.
+
+### OAuth tokens redirect
+
+Potrebbe essere possibile che il sottodominio compromesso sia autorizzato a essere utilizzato nell'URL `redirect_uri` di un flusso OAuth. Questo potrebbe essere sfruttato da un attaccante per **rubare il token OAuth**.
+
+### CSP Bypass
+
+Potrebbe essere possibile che il sottodominio compromesso (o ogni sottodominio) sia autorizzato a essere utilizzato, ad esempio, per il `script-src` del CSP. Questo potrebbe essere sfruttato da un attaccante per **iniettare script dannosi** e abusare di potenziali vulnerabilità XSS.
+
 ### **Emails and Subdomain Takeover**
 
-Un altro aspetto del takeover del sottodominio coinvolge i servizi email. Gli attaccanti possono manipolare i **record MX** per ricevere o inviare email da un sottodominio legittimo, migliorando l'efficacia degli attacchi di phishing.
+Un altro aspetto del takeover del sottodominio coinvolge i servizi email. Gli attaccanti possono manipolare i **record MX** per ricevere o inviare email da un sottodominio legittimo, aumentando l'efficacia degli attacchi di phishing.
 
 ### **Higher Order Risks**
 
-Ulteriori rischi includono il **takeover dei record NS**. Se un attaccante ottiene il controllo su un record NS di un dominio, può potenzialmente indirizzare una parte del traffico a un server sotto il proprio controllo. Questo rischio è amplificato se l'attaccante imposta un alto **TTL (Time to Live)** per i record DNS, prolungando la durata dell'attacco.
+Ulteriori rischi includono il **takeover dei record NS**. Se un attaccante guadagna il controllo su un record NS di un dominio, può potenzialmente indirizzare una parte del traffico a un server sotto il proprio controllo. Questo rischio è amplificato se l'attaccante imposta un alto **TTL (Time to Live)** per i record DNS, prolungando la durata dell'attacco.
 
 ### CNAME Record Vulnerability
 
@@ -77,5 +93,6 @@ Per i fornitori di cloud, verificare la proprietà del dominio è cruciale per p
 
 - [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/)
 - [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide)
+- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20)
 
 {{#include ../banners/hacktricks-training.md}}

src/pentesting-web/hacking-with-cookies/README.md

@@ -111,7 +111,7 @@ Questo attacco comporta il furto del cookie di un utente per ottenere accesso no
 
 ### Session Fixation
 
-In questo scenario, un attaccante inganna una vittima per utilizzare un cookie specifico per accedere. Se l'applicazione non assegna un nuovo cookie al momento del login, l'attaccante, in possesso del cookie originale, può impersonare la vittima. Questa tecnica si basa sul fatto che la vittima accede con un cookie fornito dall'attaccante.
+In questo scenario, un attaccante inganna una vittima a utilizzare un cookie specifico per accedere. Se l'applicazione non assegna un nuovo cookie al momento del login, l'attaccante, in possesso del cookie originale, può impersonare la vittima. Questa tecnica si basa sul fatto che la vittima accede con un cookie fornito dall'attaccante.
 
 Se hai trovato un **XSS in un sottodominio** o **controlli un sottodominio**, leggi:
 
@@ -157,7 +157,7 @@ setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value
 ```
 Questo porta il browser a inviare un'intestazione cookie interpretata da ogni server web come un cookie chiamato `a` con un valore `b`.
 
-#### Chrome Bug: Problema del Codice Surrogato Unicode
+#### Bug di Chrome: Problema del Codice Surrogato Unicode
 
 In Chrome, se un codice surrogato Unicode fa parte di un cookie impostato, `document.cookie` diventa corrotto, restituendo successivamente una stringa vuota:
 ```js
@@ -179,24 +179,49 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
 - Zope cerca una virgola per iniziare a analizzare il cookie successivo.
 - Le classi di cookie di Python iniziano a analizzare su un carattere di spazio.
 
-Questa vulnerabilità è particolarmente pericolosa nelle applicazioni web che si basano sulla protezione CSRF basata su cookie, poiché consente agli attaccanti di iniettare cookie CSRF-token falsificati, potenzialmente eludendo le misure di sicurezza. Il problema è aggravato dalla gestione di nomi di cookie duplicati da parte di Python, dove l'ultima occorrenza sovrascrive quelle precedenti. Solleva anche preoccupazioni per i cookie `__Secure-` e `__Host-` in contesti insicuri e potrebbe portare a bypass di autorizzazione quando i cookie vengono passati a server di backend suscettibili alla falsificazione.
+Questa vulnerabilità è particolarmente pericolosa nelle applicazioni web che si basano sulla protezione CSRF basata su cookie, poiché consente agli attaccanti di iniettare cookie CSRF-token falsificati, potenzialmente eludendo le misure di sicurezza. Il problema è aggravato dalla gestione dei nomi di cookie duplicati da parte di Python, dove l'ultima occorrenza sovrascrive quelle precedenti. Solleva anche preoccupazioni per i cookie `__Secure-` e `__Host-` in contesti insicuri e potrebbe portare a bypass di autorizzazione quando i cookie vengono passati a server di backend suscettibili alla falsificazione.
 
-### Cookies $version e bypass dei WAF
+### Cookies $version
+
+#### Bypass WAF
 
 Secondo [**questo blogpost**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), potrebbe essere possibile utilizzare l'attributo del cookie **`$Version=1`** per far sì che il backend utilizzi una logica obsoleta per analizzare il cookie a causa del **RFC2109**. Inoltre, altri valori come **`$Domain`** e **`$Path`** possono essere utilizzati per modificare il comportamento del backend con il cookie.
 
-#### Analisi del bypass dei valori con codifica di stringhe tra virgolette
+#### Attacco Cookie Sandwich
 
-Questa analisi indica di disattivare l'escape dei valori all'interno dei cookie, quindi "\a" diventa "a". Questo può essere utile per bypassare i WAFS poiché:
+Secondo [**questo blogpost**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique), è possibile utilizzare la tecnica del cookie sandwich per rubare cookie HttpOnly. Questi sono i requisiti e i passaggi:
+
+- Trovare un luogo dove un apparente **cookie inutile è riflesso nella risposta**
+- **Creare un cookie chiamato `$Version`** con valore `1` (puoi farlo in un attacco XSS da JS) con un percorso più specifico in modo che ottenga la posizione iniziale (alcuni framework come Python non necessitano di questo passaggio)
+- **Creare il cookie che viene riflesso** con un valore che lascia un **aperto doppio apice** e con un percorso specifico in modo che sia posizionato nel database dei cookie dopo il precedente (`$Version`)
+- Poi, il cookie legittimo andrà successivamente nell'ordine
+- **Creare un cookie fittizio che chiude le virgolette** all'interno del suo valore
+
+In questo modo, il cookie della vittima viene intrappolato all'interno del nuovo cookie versione 1 e verrà riflesso ogni volta che viene riflesso.
+```javascript
+document.cookie = `$Version=1;`;
+document.cookie = `param1="start`;
+// any cookies inside the sandwich will be placed into param1 value server-side
+document.cookie = `param2=end";`;
+```
+### WAF bypasses
+
+#### Cookies $version
+
+Controlla la sezione precedente.
+
+#### Bypassing value analysis with quoted-string encoding
+
+Questo parsing indica di disattivare l'escape dei valori all'interno dei cookie, quindi "\a" diventa "a". Questo può essere utile per bypassare i WAF come:
 
 - `eval('test') => forbidden`
 - `"\e\v\a\l\(\'\t\e\s\t\'\)" => allowed`
 
-#### Bypassare le blacklist dei nomi dei cookie
+#### Bypassing cookie-name blocklists
 
-Nell'RFC2109 è indicato che una **virgola può essere utilizzata come separatore tra i valori dei cookie**. È anche possibile aggiungere **spazi e tabulazioni prima e dopo il segno di uguale**. Pertanto, un cookie come `$Version=1; foo=bar, abc = qux` non genera il cookie `"foo":"bar, admin = qux"` ma i cookie `foo":"bar"` e `"admin":"qux"`. Nota come vengono generati 2 cookie e come "admin" ha rimosso lo spazio prima e dopo il segno di uguale.
+Nell'RFC2109 è indicato che una **virgola può essere usata come separatore tra i valori dei cookie**. Ed è anche possibile aggiungere **spazi e tabulazioni prima e dopo il segno di uguale**. Pertanto, un cookie come `$Version=1; foo=bar, abc = qux` non genera il cookie `"foo":"bar, admin = qux"` ma i cookie `foo":"bar"` e `"admin":"qux"`. Nota come vengono generati 2 cookie e come "admin" ha rimosso lo spazio prima e dopo il segno di uguale.
 
-#### Analisi del bypass dei valori con divisione dei cookie
+#### Bypassing value analysis with cookie splitting
 
 Infine, diverse backdoor si unirebbero in una stringa diversi cookie passati in intestazioni di cookie differenti come in:
 ```
@@ -220,7 +245,7 @@ Resulting cookie: name=eval('test//, comment') => allowed
 - Disconnettiti e prova a usare lo stesso cookie.
 - Prova ad accedere con 2 dispositivi (o browser) allo stesso account usando lo stesso cookie.
 - Controlla se il cookie contiene informazioni e prova a modificarlo.
-- Prova a creare diversi account con quasi lo stesso nome utente e controlla se puoi vedere somiglianze.
+- Prova a creare diversi account con nomi utente quasi identici e controlla se puoi vedere somiglianze.
 - Controlla l'opzione "**ricordami**" se esiste per vedere come funziona. Se esiste e potrebbe essere vulnerabile, usa sempre il cookie di **ricordami** senza alcun altro cookie.
 - Controlla se il cookie precedente funziona anche dopo aver cambiato la password.
 
@@ -229,7 +254,7 @@ Resulting cookie: name=eval('test//, comment') => allowed
 Se il cookie rimane lo stesso (o quasi) quando accedi, questo probabilmente significa che il cookie è legato a qualche campo del tuo account (probabilmente il nome utente). Allora puoi:
 
 - Provare a creare molti **account** con nomi utente molto **simili** e cercare di **indovinare** come funziona l'algoritmo.
-- Provare a **bruteforce il nome utente**. Se il cookie viene salvato solo come metodo di autenticazione per il tuo nome utente, allora puoi creare un account con il nome utente "**Bmin**" e **bruteforce** ogni singolo **bit** del tuo cookie perché uno dei cookie che proverai sarà quello appartenente a "**admin**".
+- Provare a **bruteforce il nome utente**. Se il cookie viene salvato solo come metodo di autenticazione per il tuo nome utente, allora puoi creare un account con nome utente "**Bmin**" e **bruteforce** ogni singolo **bit** del tuo cookie perché uno dei cookie che proverai sarà quello appartenente a "**admin**".
 - Prova **Padding** **Oracle** (puoi decrittare il contenuto del cookie). Usa **padbuster**.
 
 **Padding Oracle - Esempi di Padbuster**