Restituisce Access-Control-Allow-Origin: * indebolisce la sicurezza delle risposte JSON GET?

6

La raccomandazione CORS W3C afferma:

Certain types of resources should not attempt to specify particular authorized origins, but instead either deny or allow all origins.

...

3. A GET response whose entity body happens to parse as ECMAScript can return an Access-Control-Allow-Origin header whose value is "*" provided there are no sensitive comments as it can be accessed cross-origin using an HTML script element. If needed, such resources can implement access control and CSRF protections as described above.

JSON analizza come ECMAScript?

È possibile che JSON produca effetti collaterali quando viene eseguito tramite un elemento di script HTML?

I contenuti web di origine incrociata possono ottenere l'accesso in lettura alle risposte JSON GET dalle richieste CSRF create tramite un elemento di script HTML?

Che cosa significa "commenti sensibili" in questo contesto?

Questo paragrafo si applica alle richieste GET che non accettano i cookie o l'autenticazione HTTP per l'autorizzazione? Ad esempio, se una richiesta fosse autorizzata solo da OAuth, la sua risposta non sarebbe accessibile a un browser tramite un elemento di script HTML. Ma facendo in modo che la sua risposta includesse Access-Control-Allow-Origin: * per tutte le richieste autorizzate, il server perderebbe la possibilità di specificare le origini a cui il browser avrebbe concesso l'accesso.

Non includere Access-Control-Allow-Origin: * indebolire la sicurezza delle risposte alle richieste autorizzate dai cookie o dall'autenticazione HTTP? Se una richiesta fosse autorizzata dai cookie, ad esempio, sarebbe eseguibile dal browser, ma il codice sorgente nel corpo della risposta non sarebbe accessibile ai contenuti web di origine incrociata. Rendendo la sua risposta include Access-Control-Allow-Origin: * , il server comunica al browser che i contenuti web di tutte le origini dovrebbero avere accesso per leggere la risposta oltre a eseguirla.

    
posta Matt McClure 16.10.2013 - 12:23
fonte

1 risposta

2

Questo lo hai già capito: l'idea principale qui è che gli elementi di script ( <script src="http://example.com/myscript.js">)nonsonosoggettiarestrizionidellastessaorigine.Pertanto,unsitopuòcaricarequalsiasiURLdiscripteeseguiretalescript(acondizionecheloscriptnonrichiedacredenzialiocheilbrowserdispongadellecredenzialinecessarieperaccederealloscript).Tuttavia,ilbrowsernonpuòleggereunoscriptcaricatoinunelemento<script>.

PotrestiriformulareilconsigliodelW3Ccome:

Ifalltheinformationinaresourcecanbeobtainedbyrunningtheresourceasascript,thenyoumayfreelyaddAccess-Control-Allow-Origin:*.

Pertanto,JSONnonsoddisfaquestorequisito.Seeseguiloscript:

(["foo", 5, 7])

quindi nessuna informazione viene aggiunta all'ambiente di esecuzione. (Qualche anno fa, potrebbe avere, per ridefinizione del costruttore Array , ma i browser moderni hanno eliminato questa vulnerabilità.)

Tuttavia, lo script

window.secrets = ["foo", 5, 7];

fa apporta una modifica osservabile all'ambiente di esecuzione. Puoi anche consentire a qualsiasi pagina di recuperare il contenuto della risorsa tramite Ajax, perché non contiene informazioni che la pagina non può apprendere eseguendo lo script in un elemento <script> .

La frase "commenti sensibili" si riferisce ai commenti effettivi del codice JavaScript ( /* e.g., like this */ ). I commenti non sono leggibili da un'esecuzione di <script> , ma potrebbero essere letti quando si accede al contenuto dello script tramite Ajax. Ad esempio, lo script:

// by the way, the fourth secret is "bar"
window.secrets = ["foo", 5, 7]

perde le stesse informazioni dell'esempio precedente quando viene eseguito in un tag <script> , poiché il commento è visibile solo durante la visualizzazione del testo effettivo dello script.

Se la risorsa richiede le credenziali OAuth e non accetta le credenziali dei cookie, sezione 4 indica:

requests ought to set the omit credentials flag and resources ought to perform authorization using security tokens explicitly provided in the content of the request

Le richieste di origine incrociata tramite gli elementi di script HTML non includevano mai le credenziali OAuth e tali richieste non sarebbero autorizzate indipendentemente dal valore dell'intestazione Access-Control-Allow-Origin della risposta.

Se la risorsa richiede credenziali e preflight, la risposta di preflight deve anche essere pubblicata con Access-Control-Allow-Credentials: true . Se il server non invia quell'intestazione, un sito non può inviare una richiesta con credenziali interdominio per leggere il contenuto dello script. Pertanto, Access-Control-Allow-Origin: * non indebolisce la sicurezza della risorsa protetta dalle credenziali, poiché le credenziali per il dominio di destinazione non verranno inviate su Ajax a meno che il server non imposti anche Access-Control-Allow-Credentials: true .

Se la risorsa richiede credenziali ma non preflight, le credenziali verranno inviate nella richiesta prima che il server abbia la possibilità di includere Access-Control-Allow-Credentials: true nella risposta. Il risultato finale è lo stesso: il browser non condivide la risposta con il contenuto web di origine incrociata che effettua la richiesta, ma per ragioni diverse.

Sezione 6.1 dice:

The string "*" cannot be used for a resource that supports credentials.

E il controllo della condivisione delle risorse passerebbe attraverso il passaggio 2 della sezione 7.2 e fallire al passaggio 3:

  1. If the Access-Control-Allow-Origin header value is the "*" character and the omit credentials flag is set, return pass and terminate this algorithm.
  2. If the value of Access-Control-Allow-Origin is not a case-sensitive match for the value of the Origin header as defined by its specification, return fail and terminate this algorithm.
    
risposta data 16.10.2013 - 19:15
fonte

Leggi altre domande sui tag