Per quanto riguarda OAuth 2.0: i cookie di terze parti abilitano una dipendenza?

Question

Quando si bloccano i cookie di terze parti utilizzando Google Chrome (più recente), si compilano 27 Win7/PC, ho visto che quasi tutti gli accessi OAuth da altri siti non funzionano, ad eccezione di accedere con G +. Ho già effettuato l'accesso con Google, quindi il cookie esiste.

• È questo il comportamento che è in realtà una dipendenza di OAuth2.0, richiedendo cookie terze parti per essere attivato?
• È una conseguenza dell'implementazione prevalente di OAuth?
• È qualcosa che dipende dal client?
• Proviene da come Chrome definisce cosa sono i "cookie di terze parti"?

Grazie a tutti per l'aiuto e il tempo! Non riesco a trovare alcuna fonte che chiarisca il problema per me.

Answer 1

Per le applicazioni Web, è richiesta una sorta di memoria di archiviazione locale ("MUST ...") dalle specifiche OAuth 2.0 come parte della difesa contro la falsificazione di richieste tra siti (CSRF). La specifica suggerisce i cookie o l'archiviazione locale HTML5 in particolare, con i cookie come un'implementazione prevalente come mostrano le tue osservazioni.

Riferimento RFC 6749 - The OAuth 2.0 Authorization Framework troviamo (enfasi aggiunta):

10. Considerazioni di sicurezza

    Come un quadro flessibile ed estensibile, di OAuth considerazioni di sicurezza dipendono molti fattori Le sezioni seguenti forniscono agli implementatori le linee guida sulla sicurezza incentrate sui tre profili client descritti nella Sezione 2.1: applicazione Web, , applicazione basata su user-agent e applicazione nativa.

...

10,12. Cross-Site Request Forgery

Cross-site request forgery (CSRF) è un exploit in cui un utente malintenzionato fa sì che l'user-agent di una vittima per l'utente finale di seguire un malintenzionato URI (ad esempio, fornito alla dall'utente agente come link ingannevole, immagine o reindirizzamento ) a un server trusting (in genere stabilito tramite la presenza di un cookie di sessione valido tramite la funzione ).

Un CSRF attacco contro il reindirizzamento del cliente URI permette ad un aggressore per iniettare il proprio codice di autorizzazione o token di accesso, che può risultato nel client utilizzando un token di accesso associate alle risorse protette della dell'attaccante piuttosto che della vittima (ad esempio, , salvare le informazioni sul conto bancario della vittima su una risorsa protetta controllata dall'hacker).

Il client DEVE implementare la protezione CSRF per il suo URI di reindirizzamento. Questo in genere viene eseguito richiedendo qualsiasi richiesta inviata all'endpoint URI di reindirizzamento per includere un valore che associa la richiesta allo stato autenticato dello user-agent (ad esempio, un hash del cookie della sessione utilizzato per autenticare l'utente-agente). Il client DOVREBBE utilizzare il parametro di richiesta "stato" per inviare questo valore al server di autorizzazione quando si effettua una richiesta di autorizzazione.

Una volta che l'autorizzazione è stata ottenuta da l'utente finale, il server di autorizzazione reindirizza user-agent del l'utente finale al client con il valore vincolante richiesta contenuta nel parametro "stato" . Il valore di binding consente al client di verificare la validità della richiesta abbinando il valore di binding allo stato autenticato dello user-agent . Il valore di binding utilizzato per la protezione CSRF DEVE contenere un valore non ipotizzabile (come descritto in sezione 10.10) e lo stato autenticato dello user-agent (ad esempio, cookie di sessione, archiviazione locale HTML5) DEVE essere conservato in una posizione accessibile solo al client e all'agente utente (ovvero protetto dalla politica della stessa origine ).