Sfruttamento CORS e POC [chiuso]

The Access-Control-Allow-Origin response header indicates whether the response can be shared with resources with the given origin.

(Da MDN)

Quando il server invia Access-Control-Allow-Origin: * , consente a qualsiasi origine di accedere alla risorsa in una richiesta di origine incrociata. Ma la misura in cui questo è sfruttabile varia.

Diciamo che hai effettuato l'accesso per il banking online a https://yourbank.example/ e il sito imposta l'intestazione ACAO. Allo stesso tempo, stai visitando un sito controllato da un utente malintenzionato in un'altra scheda. Ora, il sito dell'aggressore potrebbe caricare uno script che invia una richiesta di origine incrociata al pannello di controllo bancario online in background, sulla falsariga di:

fetch('https://yourbank.example/').then(r => r.text()).then(console.log)

In quel caso il tuo browser rivelerebbe la tua vista di https://yourbank.example/ all'attaccante. Tuttavia , questo non è utile, perché il tuo browser non include i dettagli di autenticazione (ad esempio i cookie di sessione) nella richiesta per impostazione predefinita. Quindi tutto ciò che l'utente malintenzionato ottiene è la tua vista non autenticata del sito web della tua banca.

Anche se il sito invia anche Access-Control-Allow-Credentials: true (dove solitamente l'utente malintenzionato può chiamare fetch() con {credentials: 'include'} per leggere la risposta di una richiesta di origine incrociata autenticata ) sei fuori fortuna perché allow-credentials non ha alcun effetto quando ACAO è impostato su carattere jolly ( * ).

Quindi, con ACAO: * da solo, ti ritroverai con scenari di attacco meno probabili. Ad esempio, potrebbe funzionare su un sito intranet o su un'interfaccia router che visualizza informazioni riservate anche senza autenticazione ma non è direttamente accessibile all'utente malintenzionato. (In tal caso potrebbe anche essere vulnerabile a rebinding DNS .)

L'invio di Access-Control-Allow-Origin: * non significa che l'endpoint sia generalmente sfruttabile. Ad esempio potrebbe essere perfettamente adatto per un endpoint API pubblico che è stato progettato per essere accessibile da chiunque.

Sarebbe comunque sfruttabile se l'endpoint restituisce dati sensibili al contesto in base a un contesto utente generato dai cookie di sessione. In questo caso, un sito Web dannoso potrebbe richiedere dati dall'endpoint nel contesto di un utente e perdere dati personali o inviare dati all'endpoint e impersonare l'utente.