Qual è l'applicabilità di CORS?

1

Ho un sistema che ha bisogno di fare richieste di origine incrociata e difficoltà nel comprendere la rilevanza di CORS . A prima vista non sembra fornirmi alcun tipo di sicurezza che vorrei realmente per il mio servizio.

  1. Dato che CORS è onorato solo sul lato client, il mio server deve comunque formulare presupposti zero sulla richiesta. Non vi è alcuna garanzia che una richiesta provenga da un browser, quindi le intestazioni CORS non possono essere utilizzate come controllo di accesso.

  2. Il server di destinazione decide chi è autorizzato a parlare con esso e il server di origine non ha alcun controllo. Anche il mio JavaScript non è sicuro sul client e soggetto a modifiche. Un server malevolo potrebbe semplicemente accettare tutte le richieste CORS e quindi tutti i dati potrebbero fuoriuscire dalla mia applicazione.

Vedo solo un ambito ristretto in cui CORS è effettivamente utile. Questo è lo scenario di Facebook. Le restrizioni di origine incrociata predefinite impediscono a una pagina malevola di inoltrare richieste a Facebook per conto dell'utente. CORS semplicemente consente a determinati domini di farlo. Tuttavia, non vedo ancora il valore in CORS qui perché alcune semplici configurazioni DNS consentirebbero lo stesso comportamento.

Quindi cosa mi manca di CORS? In quali scenari è rilevante e vantaggioso utilizzare (rispetto ai DNS CNAME semplici)?

    
posta edA-qa mort-ora-y 15.02.2014 - 18:34
fonte

2 risposte

3

Ogni volta che scrivo un servizio RESTful, inserisco le intestazioni CORS in modo che possa leggerlo da un'applicazione javascript / browser arbitraria.

I motivi sono:

1) CORS è interamente basato sulla sicurezza lato client e NON ha EFFETTO sulla sicurezza lato server. (Questo è stato il punto principale che mi ha confuso quando ho iniziato a guardarlo.)

2) Fornisco sempre comunque alcuni meccanismi di sicurezza come OAuth, in modo che la restrizione di origine incrociata del browser sia debole e ridondante.

3) Un utente malintenzionato può banalmente sollevare un servizio proxy che riceve richieste e le indirizza al tuo servizio. Il proxy non si preoccupa della restrizione della stessa origine, che sconfigge la restrizione nel browser.

Ma per me, la risposta breve è che i miei dati sono protetti con qualche schema di autorizzazione come OAuth, oppure non è protetto e non mi interessa se (o attivamente lo vuoi) arriva un browser arbitrario e lo ottiene.

La BTW in piedi su un proxy sullo stesso server che serve le pagine è l'altro modo ufficiale per sconfiggere la restrizione della stessa origine. ;) Devo farlo per i servizi RESTful che integro ma non possiedo. ... Se lo stai facendo, fornisci alcuni limiti in modo che il proxy non diventi un portale completamente aperto per la tua infrastruttura interna.

Ulteriori informazioni sulle intestazioni CORS qui: link

    
risposta data 16.02.2014 - 05:04
fonte
1

Bene, il primo e più ovvio scenario è quando vuoi davvero consentire a tutti di chiamare il tuo servizio. Supponiamo che tu disponga di un repository di dati pubblico che desideri incoraggiare altre persone a utilizzare e sviluppare interfacce per. Senza CORS, le app web si limitano a fare in modo che l'utente chiami il server di interfaccia e faccia una richiesta di webservice e poi risponda all'utente con tali informazioni - lo sviluppatore dell'interfaccia agisce come proxy, che potrebbe non essere in grado di permettersi / voglio fare. Con CORS il tuo repository può essere aggiunto da chiunque, e quindi l'interfaccia può essere javascript puro.

In secondo luogo, la tua prima obiezione è irrilevante - mentre le intestazioni COR non possono essere usate per l'accesso ad altre intestazioni e il corpo della richiesta certamente può.

Per quanto riguarda la seconda obiezione - in genere, non si inviano informazioni al secondo server, si ottengono informazioni da esso. E se non ti fidi del secondo server la tua app non deve usarlo.

    
risposta data 15.02.2014 - 19:14
fonte

Leggi altre domande sui tag