Che tipo di sicurezza proviene dal blocco delle richieste di origine incrociata quando esiste il cors? [duplicare]

-1

I browser moderni bloccano le richieste di origine incrociata.

Ciò significa che sarà bloccato:

jQuery.get("https://example.net");

Perché bloccare quelle richieste?

  • non va bene quando il contenuto viene caricato l'utente non ha richiesto esplicitamente (ad es. annunci)

Ma ora, c'è CORS. Ciò significa che il server decide, se la richiesta verrà bloccata .

Pro:

  • API
  • database della conoscenza

Contro:

  • beh, anche le pubblicità vanno viste. Ciò significa che i contenuti dannosi non vengono interrotti se il contenuto vuole essere visto.

Ciò significa che è facile aggirare il blocco, usando un proxy che non si blocca e dice di voler condividere il suo contenuto (Allow-cross-origin-requests). (Esempio: cors.io ) Ma questo aggiunge altri rischi - dal momento che un altro sito deve essere considerato affidabile e l'intera funzionalità della pagina di origine non funziona più, quando un sito smette di rispondere.

Quindi che tipo di sicurezza proviene dal blocco delle richieste di origine incrociata?

    
posta Asqiir 22.06.2018 - 10:05
fonte

2 risposte

0

OK, sia la domanda che la risposta di Geir mostrano una certa confusione, quindi cercherò di chiarire un po 'le cose ...

La politica della stessa origine (SOP) è una funzionalità di sicurezza del browser che limita l'interazione tra i siti web. In generale, impedisce al sito A di visualizzare il contenuto del sito B. Questo è importante, perché altrimenti se si è connessi a un sito come Facebook, qualsiasi altro sito che desidera potrebbe visualizzare e persino intraprendere azioni nel tuo profilo Facebook! Ciò si applicherebbe anche a cose come il banking online, lo shopping o la gestione aziendale. È necessario per la sicurezza di qualsiasi sito web che richiede di accedere o di autenticarsi in altro modo.

Alcuni di ciò che SOP impedisce è abbastanza semplice da comprendere, come con XHR (XMLHttpRequest) e Fetch, dove impedisce al sito richiedente di vedere il contenuto della risposta. Tuttavia, NON impedisce l'invio della richiesta, nella maggior parte dei casi (per impostazione predefinita, blocca alcuni tipi di richieste avanzate tra più siti, come ad esempio header). Dopo tutto, non c'è motivo di impedire semplici richieste - GET o POST con tipi di contenuto standard - perché un sito Web malevolo A che voleva attaccare B poteva semplicemente creare un modulo HTML che automaticamente si sottometteva a B con qualsiasi dato inserito dall'aggressore, e tutti i cookie dell'utente per B sarebbero inclusi nella richiesta. SOP impedisce anche la maggior parte delle interazioni tra iframe e le loro pagine padre.

Tuttavia, ci sono alcune cose che SOP non impedisce. Ad esempio, una pagina Web può includere script e immagini da siti esterni. Poiché la pubblicità sul Web viene quasi sempre eseguita caricando immagini e script da siti esterni (e per tale motivo, il monitoraggio Web funziona allo stesso modo), SOP non impedisce la pubblicità in generale. Anche SOP non impedisce CSRF , a meno che non venga utilizzata una protezione come un token anti-CSRF, nel qual caso SOP è importante (altrimenti il sito attaccante potrebbe solo leggere il token anti-CSRF dal sito di destinazione , quindi inviarlo con la richiesta forgiata.

Cross-Origin Resource Sharing (CORS) è un modo per il sito B di dire a un browser "hey, voglio che tu rilassi la politica della stessa origine riguardo al sito A, ma solo in questi modi molto specifici ". Più specificamente, la cosa più basilare che CORS può fare è consentire alle richieste XHR e Fetch standard (che sono state fatte usando JS) di leggere il contenuto della risposta, che normalmente non è permesso. Può anche consentire cose più complicate, come consentire al sito A di impostare intestazioni di richieste HTTP personalizzate specificate (che in genere non sono consentite) o tipi di contenuto al di fuori di quelli che gli elementi HTML possono inviare (che di norma non è consentito). Ad esempio, CORS potrebbe essere utilizzato per consentire a due siti che si fidano l'un l'altro (come security.stackexchange.com e stackoverflow.com) per condividere le informazioni utilizzando le richieste lato client. Oppure potrebbe essere utilizzato per fornire un'API di servizi Web che un sito come Twitter può utilizzare per mostrare a livello di codice il contenuto dei tweet ad altri siti, sempre sul lato client (ovvero senza che il browser debba chiedere al server del sito corrente di inviare quella richiesta per esso).

Tuttavia, per essere chiari, CORS non "protegge" nulla. Tutti i CORS possono fare buchi nella protezione di SOP. CORS è stato sviluppato per fornire un modo più sicuro attorno a SOP rispetto alle cose che alcuni siti stavano facendo, come JSONP (che era un trucco intelligente ma un pasticcio di sicurezza). CORS ti consente di rilassare SOP solo nei modi che desideri, solo per i siti che desideri.

Speriamo che questo risponda anche perché sia SOP che CORS sono utili. In generale, non dovresti abilitare CORS sul tuo server (cioè inviare intestazioni di risposta CORS) a meno che non sia necessario, e se necessario, dovresti abilitarlo solo per le cose che ne hanno bisogno. Ho visto alcuni siti che usano CORS in modo così liberale da aver praticamente disattivato SOP per l'intero sito, il che consentirebbe a qualsiasi sito malevolo sull'intera vista di Internet e controllare il sito mal configurato per qualsiasi utente che fosse loggato e visitato un sito dannoso.

    
risposta data 23.06.2018 - 04:22
fonte
-1

L'utilizzo di un proxy come intermediario per l'iniezione di intestazioni CORS non funzionerebbe, perché le credenziali (cookie) sono soggette a regole simili come lo stesso fetch remoto ().

Lo stesso criterio di origine limita il modo in cui il sito di un utente malintenzionato può richiamare risorse su un altro sito a cui si è effettuato l'accesso. E CORS ti consente (come fornitore API) di allentare tali regole per i siti Web di cui ti fidi. L'idea è che il browser, in qualità di agente fidato, convalidi che il sito Web sia effettivamente autorizzato a fare ciò che tenta di fare.

Supponete di essere indotti a navigare nel link , dove un XHR chiama la risorsa dei fondi di trasferimento presso la vostra banca. Il sito dell'aggressore tenta qualcosa del tipo:

POST /transfer/ Content-Type: application/json Host: yourbank.com Cookie: ???? Origin: https://evil.org
{toAccount: "attackersaccount", amount: "1000USD"}

Se hai già effettuato l'accesso alla tua banca e il browser consentirebbe alla pagina di includere le tue credenziali (ad es. cookie di sessione), il trasferimento verrebbe approvato.

O sarebbe, senza la politica della stessa origine e CORS. Per essere sicuri che la pagina possa chiamare le risorse su un'API remota, verrebbe controllato con l'API (un prefligh CORS) utilizzando il metodo OPTIONS. Poiché l'API non ha mai sentito parlare dell'origine "evil.com", rifiuta di completare la chiamata.

Se hai provato ad aggiungere un proxy come intermediario qui; dove la tua risorsa proxy "evil.org" inoltra le chiamate alla risorsa bancaria, qualsiasi cookie su "yourbank.com" verrebbe semplicemente omesso perché non corrisponde al dominio proxy "evil.com".

Spero che questo spieghi perché il meccanismo CORS è posto sul lato API. Come sottolinea MDHacker, qui ci sono molti dettagli da conoscere. Devo cercare di mantenere la risposta corrispondente al nucleo della domanda.

    
risposta data 22.06.2018 - 21:41
fonte

Leggi altre domande sui tag