Perché è richiesto Access-Control-Allow-Origin per le richieste cross-domain noncredenziali? [duplicare]

Question

Perché è richiesto Access-Control-Allow-Origin per le richieste cross-domain noncredenziali? [duplicare]

#1 da (2 voti)

3

Comprendo CSRF e perché le richieste AJAX inter-dominio con cookie o altre credenziali non possono essere consentite senza un'intestazione Access-Control-Allow-Credentials esplicitamente consentendole, altrimenti sarei in grado di fare cose come adescare le persone in un sito che dirotta i loro cookie di Facebook per pubblicare qualcosa su Facebook nel loro nome.

Ciò che non capisco è perché anche le richieste AJAX tra domini non registrate non siano consentite senza un'intestazione Access-Control-Allow-Origin . Senza le credenziali coinvolte, CSRF sembra impossibile e quindi gli unici argomenti che conosco per la stessa politica di origine sembrano non applicarsi. A quale vulnerabilità sarebbero esposti i siti o gli utenti se questa restrizione non fosse in vigore?

http csrf same-origin-policy

posta Mark Amery 21.08.2013 - 17:54

fonte

1 risposta

Leggi altre domande sui tag http csrf same-origin-policy

Gli strumenti di collaborazione basati sul cloud sono "sicuri"? I registri dei visitatori mostrano \ x80w \ x01 \ x03 \ x01 l'HNAP1

score 2 · Accepted Answer

Sei incappato in un po 'di un'irregolarità causata dal tentativo di fare degli standard sicuri. In breve, gli exploit CSRF non possono utilizzare un XHR CORS a causa della richiesta preliminare di requst , attaccanti sono costretti ad usare altre tecniche. In un XHR, puoi leggere la risposta. Tuttavia in un attacco CSRF, l'attaccante non si preoccupa di leggere la risposta. Un exploit CSRF basato su GET può essere solo un semplice tag <img> . Un exploit CSRF basato su POST è il seguente:

<form id="csrf_exploit" action="https://victim_site/passsword_change" method="POST">
  <input name="new_password" value="hacked">
  <input name="repeat_password" value="hacked">
  <input type=submit>
</form>
<script>
  document.getElementById("csrf_exploit").submit();
</script>

Nell'esempio sopra, l'intero browser viene reindirizzato quando viene inviata la richiesta POST. Spesso un exploit come questo è collocato all'interno di un iframe per nascondere questo reindirizzamento dalla vittima. Il browser restituisce la risposta e l'attaccante ottiene i benefici dall'effetto collaterale prodotto dalla richiesta. In questo caso l'effetto collaterale sta cambiando la password dell'utente.