Se non desidero mai accettare richieste di origine incrociata, posso semplicemente ignorare CORS?

14

Le specifiche CORS indicano che se un metodo di richiesta e le intestazioni non sono semplici quindi viene inviata una richiesta HTTP OPTIONS di preflight per verificare se la richiesta è consentita dal server.

Il mio server non risponde con intestazioni specifiche CORS, quindi presumo che ciò significhi che la richiesta verrà negata. Recentemente una società di sicurezza mi ha detto che questo significa che la richiesta sarà sempre accettata se non la negherò specificamente con intestazioni CORS, ma trovo difficile crederlo.

Inoltre, alcuni browser più vecchi non implementano CORS affatto, quindi mi chiedo se c'è un buco di sicurezza qui che questi browser potrebbero essere in grado di aggirare il controllo CORS? Oppure questi browser negano sempre tutto?

Riepilogo: non desidero mai accettare richieste di origine incrociata. C'è un buco di sicurezza con il solo pretendere che CORS non esiste?

    
posta Jarrod Everett 27.08.2012 - 20:43
fonte

3 risposte

15

No. Non vi è alcun buco di sicurezza nel solo far finta che CORS non esista. CORS è una politica di opt-in. Finché il tuo server non invia mai alcuna intestazione CORS (mai attiva), i browser continueranno a utilizzare la politica della stessa origine standard. Puoi fingere che CORS non esista, per mantenere la tua vita semplice: questa è una strategia perfettamente ragionevole.

CORS è opzionale: puoi usarlo se vuoi le sue funzionalità extra, ma è anche perfettamente perfetto ignorarlo e non usarlo mai. Questo è di design. Qualunque altra cosa sarebbe pazzesca. Ci sono milioni di siti web che sono stati scritti prima di CORS e non verranno mai modificati. Progettare uno standard che da un giorno all'altro ha reso tutti quei siti Web sarebbe pazzesco. Gli scrittori degli standard CORS non sono pazzi. Non l'hanno fatto. (In effetti, hanno fatto molta fatica non per farlo!)

Sospetto che ci sia stato qualche errore di comunicazione o incomprensione con la tua ditta di sicurezza (o forse la tua compagnia di sicurezza è semplicemente sbagliata). Per quanto ne so, va bene che un'applicazione web non invii mai intestazioni CORS.

Detto questo, fai devi capire CSRF. CSRF è una vulnerabilità fondamentale sul web (una che precede molto il CORS ed è ortogonale al CORS). Quindi, ti preghiamo di leggere su di esso. Troverai molte grandi risorse su CSRF sulle pagine web OWASP e su questo sito. La difesa standard contro CSRF consiste nell'utilizzare i token CSRF per tutte le richieste HTTP che potrebbero avere effetti collaterali.

    
risposta data 28.08.2012 - 08:31
fonte
2

Stai cercando di proteggere il client o il server? Sono a conoscenza del fatto che CORS ha lo scopo di fornire un modo per le applicazioni lato client (ad esempio script) per accedere alle risorse al di fuori della "politica della stessa origine". I browser conformi agli standard non dovrebbero consentire agli script di recuperare risorse al di fuori dei loro domini (ad es. Tramite richiesta AJAX) in assenza dell'intestazione HTTP Access-Control-Allow-Origin, quindi penso che la risposta alla tua domanda sia che non hai preoccuparsi di questo Tuttavia, CORS / la politica della stessa origine viene applicata dal client, quindi non so cosa si possa fare sul lato server per negare le richieste di origine incrociata oltre a non consentirle esplicitamente con quella intestazione.

    
risposta data 27.08.2012 - 22:31
fonte
2

Quando il tuo server web riceve una richiesta, vede solo ciò che il client gli ha inviato. Non ha informazioni su ciò che accade nel browser, anche se esiste un browser (supponiamo che qualcuno abbia usato curl o wget per fare la richiesta). Quindi, la responsabilità di prevenire CSRF è principalmente del browser, e se un browser più vecchio non fa nulla per impedirlo, quelle richieste saranno onorate.

Ci sono molte tecniche per prevenire CSRF che non si occupa affatto di CORS. Uno dei più efficaci AFAIK è l'uso di un token CRSF: invia un token casuale al client (memorizzandolo nel cookie del sito) e aspettalo in ogni sottomissione che è necessario proteggere. Supponendo che tu stia utilizzando SSL, non c'è modo per un utente malintenzionato (che non ha accesso al cookie) di sapere quale sia il token, quindi non può falsificare una richiesta valida.

    
risposta data 27.08.2012 - 22:37
fonte

Leggi altre domande sui tag