FixVibe
Covered by FixVibehigh

CORS Configurazione errata: rischi di policy eccessivamente permissive

La condivisione delle risorse tra origini (CORS) è un meccanismo del browser progettato per allentare la politica della stessa origine (SOP). Sebbene necessaria per le moderne app Web, un'implementazione impropria, come l'eco dell'intestazione Origin del richiedente o l'inserimento nella whitelist dell'origine "null", può consentire ai siti dannosi di esfiltrare i dati privati ​​degli utenti.

CWE-942

Impatto

Un utente malintenzionato può rubare dati sensibili e autenticati dagli utenti di un'applicazione vulnerabile [S2]. Se un utente visita un sito Web dannoso mentre è connesso all'app vulnerabile, il sito dannoso può effettuare richieste multiorigine al API dell'app e leggere le risposte [S1][S2]. Ciò può portare al furto di informazioni private, inclusi profili utente, token CSRF o messaggi privati ​​[S2].

Causa principale

CORS è un meccanismo basato su intestazione HTTP che consente ai server di specificare quali origini (dominio, schema o porta) sono autorizzate a caricare le risorse [S1]. Le vulnerabilità in genere sorgono quando la policy CORS di un server è troppo flessibile o mal implementata [S2]:

  • Intestazione origine riflessa: alcuni server leggono l'intestazione Origin da una richiesta del client e la riproducono nell'intestazione di risposta Access-Control-Allow-Origin (ACAO) [S2]. Ciò consente effettivamente a qualsiasi sito Web di accedere alla risorsa [S2].
  • Caratteri jolly configurati in modo errato: Sebbene il carattere jolly * consenta a qualsiasi origine di accedere a una risorsa, non può essere utilizzato per richieste che richiedono credenziali (come cookie o intestazioni di autorizzazione) [S3]. Gli sviluppatori spesso tentano di aggirare questo problema generando dinamicamente l'intestazione ACAO in base alla richiesta [S2].
  • Whitelist 'null': alcune applicazioni autorizzano l'origine null, che può essere attivata da richieste reindirizzate o file locali, consentendo ai siti dannosi di mascherarsi da origine null per ottenere l'accesso a [S2][S3].
  • Errori di analisi: Errori nella regex o nella corrispondenza delle stringhe durante la convalida dell'intestazione Origin possono consentire agli aggressori di utilizzare domini come trusted-domain.com.attacker.com [S2].

È importante notare che CORS non è una protezione contro Cross-Site Request Forgery (CSRF) [S2].

Correzioni concrete

  • Utilizza una whitelist statica: Evita di generare dinamicamente l'intestazione Access-Control-Allow-Origin dall'intestazione Origin [S2]. Confronta invece l'origine della richiesta con un elenco hardcoded di domini attendibili [S3].
  • Evita l'origine "nulla": Non includere mai null nella whitelist delle origini consentite [S2].
  • Limita credenziali: imposta Access-Control-Allow-Credentials: true solo se assolutamente necessario per la specifica interazione multiorigine [S3].
  • Utilizza una convalida corretta: se è necessario supportare più origini, assicurati che la logica di convalida per l'intestazione Origin sia solida e non possa essere ignorata da sottodomini o domini dall'aspetto simile [S2].

Come lo esegue il test FixVibe

FixVibe ora lo include come controllo attivo con cancello. Dopo la verifica del dominio, active.cors invia richieste API della stessa origine con un'origine sintetica dell'aggressore ed esamina le intestazioni di risposta CORS. Segnala origini arbitrarie riflesse, credenziali jolly CORS e CORS completamente aperti su endpoint API non pubblici evitando il rumore delle risorse pubbliche.