Il CORS aiuta in ogni caso contro la falsificazione di siti incrociati?

Inizierò la mia risposta dicendo che molte persone fraintendono la Same Same Policy e cosa CORS porta al tavolo.

Alcune delle risposte sopra votate già qui affermano che la stessa politica di origine impedisce le richieste cross-site e quindi impedisce CSRF . Questo non è il caso. Tutto il SOP fa è impedire che la risposta venga letta da un altro dominio (alias origine). Questo è irrilevante se un attacco CSRF ha successo o meno.

L'unica volta che SOP entra in gioco con CSRF è quello di impedire che un token venga letto da un dominio diverso.

Tutti i CORS fa rilassare il SOP quando è attivo. Non aumenta la sicurezza, semplicemente consente alcune eccezioni. Alcuni browser con supporto CORS parziale consentono richieste XHR cross site (es. IE 10 e precedenti), tuttavia non consentono l'uso di intestazioni personalizzate essere aggiunto. Nei browser CORS supportati l'intestazione Origin non può essere impostata, impedendo a un utente malintenzionato di falsificarlo.

Ho menzionato che i domini erano di origini diverse. Le origini possono anche differire per porta e protocollo quando si parla di richieste AJAX (non tanto con i cookie).

Infine, tutto quanto sopra non ha nulla a che fare con le richieste forgiate provenienti direttamente da un utente malintenzionato, ad esempio con curl. Ricorda, l'utente malintenzionato deve utilizzare il browser della vittima per il suo attacco. Hanno bisogno del browser per inviare automaticamente i suoi cookie. Questo non può essere ottenuto da una richiesta di ricciolo diretto in quanto ciò sarebbe solo l'autenticazione dell'attaccante in questo tipo di scenario di attacco (la categoria nota come "attacchi sul lato client").

Il vantaggio di CORS è che consente al dominio di consentire la lettura da un altro dominio trusted. Quindi se hai http://data.example.org puoi impostare le intestazioni di risposta per consentire a http://site.example.com di fare richieste AJAX e recuperare i dati dalla tua API.

Stai mescolando le cose. CORS non intende proteggere la tua applicazione da richieste http predisposte , ma è pensata per proteggerti da un certo tipo di attacchi che "rubano" i cookie o i token di accesso dell'utente, controllando quali siti possono accedere alla tua risorsa .

Viene principalmente utilizzato per proteggere il server / l'applicazione dalla falsificazione di richieste cross-site, in cui un sito dannoso eseguirà una richiesta per conto dell'utente, possibilmente con intenti malevoli (modifica delle credenziali, trasferimento di denaro ...), sfruttando il Infatti, il browser invierà qualsiasi cookie di accesso e di sessione ancora vivo e valido per il tuo sito.

Se CORS è configurato correttamente, la richiesta Ajax del sito dell'aggressore verrà rifiutata, in quanto, per impostazione predefinita, accetterà solo richieste dallo stesso sito.

Questo NON significa che non dovresti disinfettare i tuoi input , e ti protegge solo da un certo tipo di attacchi CSFR. Se l'utente malintenzionato ottiene i cookie / i token di accesso dell'utente, gli sarà comunque garantito l'accesso, ed è per questo che la maggior parte dei processi di autenticazione dovrebbe utilizzare SSL come ulteriore livello di protezione.

PS: questo presuppone che il browser utilizzato dall'utente sia aggiornato, non abbia difetti e stia rispettando la stessa politica di origine.

MODIFICA: come per le richieste di verifica preliminare, questa è una misura aggiuntiva per garantire che al sito venga concesso l'accesso e non per tutte le richieste di origine incrociata

I've been reading in the last couple of days about CORS and in a lot of places it's mentioned as it is a "Security" feature to help the world from cross domain forgery.

Hai frainteso i vantaggi di CORS o forse hai letto che in alcuni blog amatoriali fatti da sviluppatori che sono più preoccupati di come farlo funzionare di < em> come renderlo sicuro (se capisci cosa intendo), perché CORS rende piuttosto la tua applicazione web vulnerabile a tali attacchi ( CSRF ) quando si aprono richieste di origine incrociata dall'origine dell'attaccante utilizzando CORS con la seguente intestazione: Access-Control-Allow-Origin: *

How is CORS helping and what's the benefit of it?

CORS è nato per alleggerire le restrizioni del SOP per le credute richieste solo . Ma i problemi iniziano esattamente con quel trust . Un utente malintenzionato potrebbe fare del male attraverso le origini forgiando richieste dannose tramite i metodi GET e POST, ad esempio, e potrebbe esporre anche rebinding DNS

Come per questa parte,

browsers will do a preflight request / server will validate the origin. But an attacker can easily create an HttpRequest top-bottom with whatever Headers(Origin) he wants and he will get access to the resource.

Da link

Additionally, for HTTP request methods that can cause side-effects on user data (in particular, for HTTP methods other than GET, or for POST usage with certain MIME types), the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP OPTIONS request method, and then, upon "approval" from the server, sending the actual request with the actual HTTP request method. Servers can also notify clients whether "credentials" (including Cookies and HTTP Authentication data) should be sent with requests.

Per quanto ne sappia, se usi i metodi HTTP come "PUT" invece di "POST" e perché fare una richiesta tra domini usando "PUT" come metodo specificato sarà sempre preceduto da una richiesta di pre-volo che verifica se l'origine è consentita, questo può prevenire gli attacchi in determinate situazioni. Questo perché l'autore dell'attacco non può falsificare l'origine in quanto i browser moderni non consentono linguaggi di scripting lato client come JavaScript per impostare "Origin" o intestazioni personalizzate cross-domain, l'attacco fallirà .

Spero di esserti stato utile.