<summary><strong>Impara l'hacking su AWS da zero a eroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.
Lo standard Cross-Origin Resource Sharing (CORS) **consente ai server di definire chi può accedere alle loro risorse** e **quali metodi di richiesta HTTP sono consentiti** da fonti esterne.
Una politica **stesso-origine** impone che un **server che richiede** una risorsa e il server che ospita la **risorsa** condividano lo stesso protocollo (ad esempio, `http://`), nome di dominio (ad esempio, `internal-web.com`), e **porta** (ad esempio, 80). In base a questa politica, solo le pagine web dello stesso dominio e porta sono autorizzate ad accedere alle risorse.
Questa intestazione può consentire **origini multiple**, un valore **`null`**, o un carattere jolly **`*`**. Tuttavia, **nessun browser supporta origini multiple**, e l'uso del carattere jolly `*` è soggetto a **limitazioni**. (Il carattere jolly deve essere usato da solo, e non è consentito il suo utilizzo insieme a `Access-Control-Allow-Credentials: true`.)
Questa intestazione è **emessa da un server** in risposta a una richiesta di risorsa tra domini avviata da un sito web, con il browser che aggiunge automaticamente un'intestazione `Origin`.
Per **default**, le richieste tra origini vengono effettuate senza credenziali come cookie o l'intestazione di autorizzazione. Tuttavia, un server tra domini può consentire la lettura della risposta quando vengono inviate credenziali impostando l'intestazione `Access-Control-Allow-Credentials` su **`true`**.
Quando si avvia una richiesta tra domini in condizioni specifiche, come l'utilizzo di un **metodo HTTP non standard** (qualsiasi cosa diversa da HEAD, GET, POST), l'introduzione di nuovi **intestazioni**, o l'impiego di un valore speciale dell'intestazione **Content-Type**, potrebbe essere necessaria una richiesta di pre-volo. Questa richiesta preliminare, sfruttando il metodo **`OPTIONS`**, serve per informare il server sulle intenzioni della prossima richiesta tra origini diverse, inclusi i metodi HTTP e le intestazioni che intende utilizzare.
Il protocollo **Cross-Origin Resource Sharing (CORS)** impone questo controllo di pre-volo per determinare la fattibilità dell'operazione tra origini diverse richiesta verificando i metodi consentiti, le intestazioni e l'affidabilità dell'origine. Per una comprensione dettagliata delle condizioni che evitano la necessità di una richiesta di pre-volo, fare riferimento alla guida esaustiva fornita da [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests).
È fondamentale notare che **l'assenza di una richiesta di pre-volo non annulla il requisito che la risposta contenga le intestazioni di autorizzazione**. Senza queste intestazioni, il browser è incapace di elaborare la risposta dalla richiesta tra origini diverse.
Considera la seguente illustrazione di una richiesta di pre-volo mirata all'utilizzo del metodo `PUT` insieme a un'intestazione personalizzata chiamata `Special-Request-Header`:
Nella risposta, il server potrebbe restituire intestazioni che indicano i metodi accettati, l'origine consentita e altri dettagli sulla politica CORS, come mostrato di seguito:
* **`Access-Control-Allow-Headers`**: Questo header specifica quali intestazioni possono essere utilizzate durante la richiesta effettiva. Viene impostato dal server per indicare le intestazioni consentite nelle richieste dal client.
* **`Access-Control-Expose-Headers`**: Attraverso questo header, il server informa il client su quali intestazioni possono essere esposte come parte della risposta oltre alle semplici intestazioni di risposta.
* **`Access-Control-Max-Age`**: Questo header indica per quanto tempo i risultati di una richiesta di pre-volo possono essere memorizzati nella cache. Il server imposta il tempo massimo, in secondi, che le informazioni restituite da una richiesta di pre-volo possono essere riutilizzate.
* **`Access-Control-Request-Headers`**: Utilizzato nelle richieste di pre-volo, questo header è impostato dal client per informare il server su quali intestazioni HTTP il client desidera utilizzare nella richiesta effettiva.
* **`Access-Control-Request-Method`**: Questo header, anch'esso utilizzato nelle richieste di pre-volo, è impostato dal client per indicare quale metodo HTTP verrà utilizzato nella richiesta effettiva.
* **`Origin`**: Questo header è impostato automaticamente dal browser e indica l'origine della richiesta cross-origin. Viene utilizzato dal server per valutare se la richiesta in arrivo dovrebbe essere consentita o negata in base alla politica CORS.
Nota che di solito (a seconda del tipo di contenuto e delle intestazioni impostate) in una richiesta **GET/POST non viene inviata alcuna richiesta di pre-volo** (la richiesta viene inviata **direttamente**), ma se si desidera accedere alle **intestazioni/corpo della risposta**, deve contenere un'intestazione _Access-Control-Allow-Origin_ che lo permetta.\
1.**`Access-Control-Request-Local-Network`**: Questo header è incluso nella richiesta del client per indicare che l'indagine è rivolta a una risorsa di rete locale. Serve come marcatore per informare il server che la richiesta proviene da all'interno della rete locale.
2.**`Access-Control-Allow-Local-Network`**: In risposta, i server utilizzano questo header per comunicare che la risorsa richiesta è autorizzata a essere condivisa con entità al di fuori della rete locale. Agisce come un segnale verde per la condivisione di risorse attraverso diverse frontiere di rete, garantendo un accesso controllato mantenendo i protocolli di sicurezza.
Una **risposta valida che consente la richiesta di rete locale** deve avere anche nella risposta l'intestazione `Access-Controls-Allow-Local_network: true`:
Si noti che l'IP **0.0.0.0** di Linux funziona per **bypassare** questi requisiti per accedere a localhost poiché quell'indirizzo IP non è considerato "locale".
È anche possibile **bypassare i requisiti della rete locale** se si utilizza l'**indirizzo IP pubblico di un endpoint locale** (come l'IP pubblico del router). Poiché in diverse occasioni, anche se si accede all'**IP pubblico**, se è **dalla rete locale**, l'accesso sarà concesso.
È stato osservato che l'impostazione di `Access-Control-Allow-Credentials` su **`true`** è un prerequisito per la maggior parte degli **attacchi reali**. Questa impostazione consente al browser di inviare credenziali e leggere la risposta, aumentando l'efficacia dell'attacco. Senza di essa, il vantaggio di far emettere una richiesta a un browser anziché farlo da soli diminuisce, poiché diventa impraticabile sfruttare i cookie di un utente.
Esiste un'eccezione in cui la posizione di rete della vittima funge da forma di autenticazione. Ciò consente al browser della vittima di essere utilizzato come proxy, aggirando l'autenticazione basata sull'IP per accedere alle applicazioni di intranet. Questo metodo presenta somiglianze nell'impatto con il reindirizzamento DNS ma è più semplice da sfruttare.
Lo scenario del mondo reale in cui il valore dell'intestazione `Origin` è riflesso in `Access-Control-Allow-Origin` è teoricamente improbabile a causa delle restrizioni sulla combinazione di queste intestazioni. Tuttavia, gli sviluppatori che desiderano abilitare CORS per più URL possono generare dinamicamente l'intestazione `Access-Control-Allow-Origin` copiando il valore dell'intestazione `Origin`. Questo approccio può introdurre vulnerabilità, in particolare quando un attaccante utilizza un dominio con un nome progettato per apparire legittimo, ingannando così la logica di convalida.
L'origine `null`, specificata per situazioni come reindirizzamenti o file HTML locali, occupa una posizione unica. Alcune applicazioni inseriscono questa origine nella whitelist per facilitare lo sviluppo locale, permettendo involontariamente a qualsiasi sito web di imitare un'origine `null` attraverso un iframe sandboxed, eludendo così le restrizioni CORS.
Quando ci si imbatte in una whitelist di dominio, è cruciale testare le opportunità di bypass, come ad esempio aggiungere il dominio dell'attaccante a un dominio in whitelist o sfruttare vulnerabilità di subdomain takeover. Inoltre, le espressioni regolari utilizzate per la convalida del dominio potrebbero trascurare le sfumature nelle convenzioni di denominazione dei domini, presentando ulteriori opportunità di bypass.
I pattern Regex di solito si concentrano su caratteri alfanumerici, punto (.), e trattino (-), trascurando altre possibilità. Ad esempio, un nome di dominio creato per includere caratteri interpretati in modo diverso dai browser e dai pattern Regex può eludere i controlli di sicurezza. Il modo in cui Safari, Chrome e Firefox gestiscono i caratteri di sottodomini sottolinea come tali discrepanze possano essere sfruttate per aggirare la logica di convalida del dominio.
**Per ulteriori informazioni e impostazioni su questo controllo di bypass:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **e** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397)
Spesso gli sviluppatori implementano meccanismi difensivi per proteggersi dall'exploit di CORS mediante l'aggiunta in whitelist di domini autorizzati a richiedere informazioni. Nonostante queste precauzioni, la sicurezza del sistema non è infallibile. La presenza anche di un singolo sottodominio vulnerabile all'interno dei domini in whitelist può aprire la porta all'exploit di CORS attraverso altre vulnerabilità, come XSS (Cross-Site Scripting).
Per illustrare, consideriamo lo scenario in cui un dominio, `requester.com`, è in whitelist per accedere a risorse da un altro dominio, `provider.com`. La configurazione lato server potrebbe assomigliare a questa:
In questa configurazione, tutti i sottodomini di `requester.com` sono autorizzati ad accedere. Tuttavia, se un sottodominio, ad esempio `sub.requester.com`, viene compromesso con una vulnerabilità XSS, un attaccante può sfruttare questa debolezza. Ad esempio, un attaccante con accesso a `sub.requester.com` potrebbe sfruttare la vulnerabilità XSS per aggirare le politiche CORS e accedere in modo dannoso alle risorse su `provider.com`.
È possibile che sfruttando l'avvelenamento della cache lato server tramite l'iniezione di intestazioni HTTP, si possa indurre una vulnerabilità XSS memorizzata. Questo scenario si verifica quando un'applicazione non sanifica l'intestazione `Origin` per i caratteri illegali, creando una vulnerabilità particolarmente per gli utenti di Internet Explorer e Edge. Questi browser trattano (0x0d) come un terminatore di intestazione HTTP legittimo, portando a vulnerabilità di iniezione di intestazioni HTTP.
Mentre sfruttare direttamente questa vulnerabilità facendo inviare al browser web un'intestazione malformata non è fattibile, una richiesta articolata può essere generata manualmente utilizzando strumenti come Burp Suite. Questo metodo potrebbe portare una cache lato server a salvare la risposta e a servirla involontariamente ad altri. Il payload articolato mira a modificare il set di caratteri della pagina in UTF-7, una codifica dei caratteri spesso associata a vulnerabilità XSS a causa della sua capacità di codificare i caratteri in modo che possano essere eseguiti come script in determinati contesti.
Per ulteriori informazioni sulle vulnerabilità XSS memorizzate, consulta [PortSwigger](https://portswigger.net/web-security/cross-site-scripting/stored).
**Nota**: Lo sfruttamento delle vulnerabilità di iniezione di intestazioni HTTP, in particolare attraverso l'avvelenamento della cache lato server, sottolinea l'importanza critica della convalida e della sanificazione di tutti gli input forniti dall'utente, inclusi gli header HTTP. Utilizza sempre un modello di sicurezza robusto che includa la convalida dell'input per prevenire tali vulnerabilità.
In questo scenario, viene osservata un'istanza di una pagina web che riflette i contenuti di un'intestazione HTTP personalizzata senza una codifica adeguata. In particolare, la pagina web riflette i contenuti inclusi in un'intestazione `X-User-id`, che potrebbe includere JavaScript dannoso, come dimostrato dall'esempio in cui l'intestazione contiene un tag di immagine SVG progettato per eseguire codice JavaScript al caricamento.
Le politiche di Cross-Origin Resource Sharing (CORS) consentono l'invio di intestazioni personalizzate. Tuttavia, senza che la risposta venga renderizzata direttamente dal browser a causa delle restrizioni CORS, l'utilità di tale iniezione potrebbe sembrare limitata. Il punto critico sorge quando si considera il comportamento della cache del browser. Se l'intestazione `Vary: Origin` non è specificata, diventa possibile che la risposta dannosa venga memorizzata nella cache del browser. Successivamente, questa risposta memorizzata potrebbe essere renderizzata direttamente durante la navigazione all'URL, eludendo la necessità di un rendering diretto alla richiesta iniziale. Questo meccanismo potenzia l'affidabilità dell'attacco sfruttando la cache lato client.
Per illustrare questo attacco, viene fornito un esempio di JavaScript, progettato per essere eseguito nell'ambiente di una pagina web, ad esempio tramite un JSFiddle. Questo script esegue un'azione semplice: invia una richiesta a un URL specificato con un'intestazione personalizzata contenente il JavaScript dannoso. Al termine con successo della richiesta, tenta di navigare all'URL di destinazione, potenzialmente attivando l'esecuzione dello script iniettato se la risposta è stata memorizzata senza una gestione adeguata dell'intestazione `Vary: Origin`.
XSSI, noto anche come Inclusione di Script da Siti Incrociati, è un tipo di vulnerabilità che sfrutta il fatto che la Politica della Stessa Origine (SOP) non si applica quando si includono risorse utilizzando il tag script. Questo perché gli script devono poter essere inclusi da domini diversi. Questa vulnerabilità consente a un attaccante di accedere e leggere qualsiasi contenuto incluso utilizzando il tag script.
Questa vulnerabilità diventa particolarmente significativa quando si tratta di JavaScript dinamico o JSONP (JSON con Padding), specialmente quando vengono utilizzate informazioni di autorità ambientale come i cookie per l'autenticazione. Quando si richiede una risorsa da un host diverso, i cookie sono inclusi, rendendoli accessibili all'attaccante.
Per comprendere meglio e mitigare questa vulnerabilità, è possibile utilizzare il plugin BurpSuite disponibile su [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp). Questo plugin può aiutare a identificare e affrontare potenziali vulnerabilità XSSI nelle vostre applicazioni web.
Prova ad aggiungere un **parametro `callback`** nella richiesta. Forse la pagina è stata preparata per inviare i dati come JSONP. In tal caso, la pagina invierà i dati con `Content-Type: application/javascript`, il che bypasserà la politica CORS.
Un modo per bypassare la restrizione `Access-Control-Allow-Origin` è richiedere a un'applicazione web di effettuare una richiesta per conto tuo e inviare la risposta. Tuttavia, in questo scenario, le credenziali della vittima finale non verranno inviate poiché la richiesta viene fatta a un dominio diverso.
1. [**CORS-escape**](https://github.com/shalvah/cors-escape): Questo strumento fornisce un proxy che inoltra la tua richiesta insieme ai suoi header, falsificando anche l'header Origin per corrispondere al dominio richiesto. Questo bypassa efficacemente la politica CORS. Ecco un esempio di utilizzo con XMLHttpRequest:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): Questo strumento offre un approccio alternativo al proxy delle richieste. Invece di passare la tua richiesta così com'è, il server effettua la propria richiesta con i parametri specificati.
È possibile **bypassare i controlli CORS** come `e.origin === window.origin`**creando un iframe** e **da esso aprendo una nuova finestra**. Maggiori informazioni nella seguente pagina:
3. Il browser della vittima memorizza nella cache la risposta DNS, che potrebbe avere un valore TTL (Time to Live) che indica per quanto tempo il record DNS deve essere considerato valido.
4. Quando il TTL scade, il browser della vittima effettua una nuova richiesta DNS, consentendo all'attaccante di eseguire codice JavaScript sulla pagina della vittima.
5. Mantenendo il controllo sull'IP della vittima, l'attaccante può raccogliere informazioni dalla vittima senza inviare alcun cookie al server della vittima.
Il DNS rebinding può essere utile per bypassare controlli IP espliciti eseguiti dalla vittima o per scenari in cui un utente o un bot rimane sulla stessa pagina per un periodo prolungato, consentendo alla cache di scadere.
Se hai bisogno di un modo rapido per abusare del DNS rebinding, puoi utilizzare servizi come [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html).
Per eseguire il proprio server DNS rebinding, puoi utilizzare strumenti come **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)). Questo comporta l'esposizione della tua porta locale 53/udp, la creazione di un record A che vi punti (ad esempio, ns.example.com) e la creazione di un record NS che punti al sottodominio A creato in precedenza (ad esempio, ns.example.com). Qualsiasi sottodominio del sottodominio ns.example.com verrà quindi risolto dal tuo host.
Puoi anche esplorare un server in esecuzione pubblica su [http://rebind.it/singularity.html](http://rebind.it/singularity.html) per una maggiore comprensione e sperimentazione.
3. Se il browser decide di utilizzare prima l'indirizzo IP dell'attaccante, l'attaccante può servire un payload che effettua richieste HTTP allo stesso dominio.
6. Accedendo al secondo indirizzo IP, il browser bypassa la Politica della Stessa Origine (SOP), consentendo all'attaccante di sfruttare ciò e raccogliere ed esfiltrare informazioni.
Questa tecnica sfrutta il comportamento dei browser quando vengono forniti più indirizzi IP per un dominio. Controllando strategicamente le risposte e manipolando la scelta dell'indirizzo IP del browser, un attaccante può sfruttare la SOP e accedere alle informazioni della vittima.
Provider come godaddy o cloudflare non mi hanno permesso di utilizzare l'IP 0.0.0.0, ma AWS route53 mi ha permesso di creare un record A con 2 IP, uno dei quali "0.0.0.0"
Puoi trovare ulteriori informazioni sulle tecniche di bypass precedenti e su come utilizzare lo strumento seguente nella presentazione [Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference](https://www.youtube.com/watch?v=y9-0lICNjOQ).
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) è uno strumento per eseguire attacchi di [DNS rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding). Include i componenti necessari per rilegare l'indirizzo IP del nome DNS del server di attacco all'indirizzo IP della macchina di destinazione e per servire payload di attacco per sfruttare software vulnerabili sulla macchina di destinazione.
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): Proposta di inviare sempre una richiesta di pre-volo quando i server pubblici vogliono accedere ai server interni
<summary><strong>Impara l'hacking AWS da zero a eroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se desideri vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
