Sono cookie HTTPOnly inviati tramite XmlHTTPRequest con withCredentials = True?

3

Ho una domanda in due parti qui.

Ho una webapp javascript che accede a endpoint REST privilegiati. Mi piacerebbe proteggere contro CSRF.

Attualmente, ho creato un sistema di login che restituisce un cookie di accesso contenente un carico utile crittografato (encrypt-then-MAC). Sono ragionevolmente sicuro che i contenuti dei cookie non possano essere manomessi o falsificati a mia insaputa.

So che l'utilizzo di detto cookie per proteggere i miei endpoint è vulnerabile a CSRF, poiché il cookie viene automaticamente inviato dal browser con qualsiasi richiesta. Credo inoltre che il pattern Double Submit Cookie sia scoraggiato perché richiede l'impostazione del valore HTTPOnly del cookie su False, che eleva il rischio di determinati attacchi.

Quello che vorrei fare è impostare il cookie auth (usato per gli accessi persistenti a medio termine) su HTTPOnly e Secure. Quindi, vorrei che il client javascript eseguisse una richiesta XHR GET su un endpoint del token in cui il cookie può essere convalidato e un token a breve termine (che contiene un handle che punta alle informazioni che ho nascosto nel mio DB) può essere emesso direttamente indietro al client, senza reindirizzamento da User Agent. Il client javascript utilizzerà quindi il token a breve termine per autorizzare le chiamate ai miei endpoint REST.

La mia prima domanda è: ci sono evidenti difetti con questo flusso? Sembra un adattamento ragionevole del modello di token di sincronizzazione per REST, ma mi piacerebbe sapere se ci sono gravi difetti o se ci sono altre buone pratiche in merito alla procedura.

Ho preso in considerazione l'implementazione del flusso di Grant implicito OAuth 2.0, ma vorrei che fosse presente il cookie auth in modo da poter mantenere gli accessi per un periodo di tempo limitato.

La seconda domanda è: il cookie HTTPOnly verrà inviato all'endpoint del token dal browser con il mio XHR se imposto conCredentials = True? So che HTTP esclude solo la capacità del javascript di leggere il cookie, ma il cookie verrà inserito nella richiesta, invisibilmente al client?

Ho cercato su Google la risposta, e il mio google-fu mi ha fallito. Tutto quello che ho trovato erano numerosi articoli su come leggere i cookie HTTPOnly, ma non inviarli.

Grazie in anticipo per qualsiasi aiuto o consiglio!

    
posta Hao Cheng 14.03.2014 - 07:48
fonte

2 risposte

3

I also believe that the Double Submit Cookie pattern is discouraged because it requires setting the cookie HTTPOnly value to False

Non richiede l'impostazione di HTTPOnly su falso. Questo è solo se si dispone di un codice JavaScript che imposterà il valore del campo modulo nascosto come il cookie. È possibile farlo senza JavaScript semplicemente inserendo il valore del cookie sul lato server di pagina (codificandolo correttamente per evitare XSS).

My first question is, are there any obvious flaws with this flow?

Questo sembra corretto perché la richiesta GET non può essere letta da un utente malintenzionato a causa della stessa politica di origine. Tuttavia, se le tue informazioni sono altamente sicure, potrebbe essere una buona idea difendersi da JSON Hijacking . Questo non è stato un problema per molto tempo (si pensi a Firefox 3) ma nel caso in cui eventuali difetti vengano reintrodotti in qualsiasi browser si potrebbe prendere passaggi di base per proteggere il tuo sito a basso costo. Ad esempio, cambiando questo in un POST e aggiungendo un cruft non analizzabile alla risposta. Questo va in qualche modo contro i principi REST, ma è qualcosa che dovrai valutare da solo.

The second question is: will the HTTPOnly cookie be submitted to the token endpoint by the browser with my XHR if I set withCredentials=True?

Sì, lo farà. HTTPOnly protegge da JavaScript stesso sul client, non influenza le richieste HTTP.

    
risposta data 15.08.2014 - 11:19
fonte
0

Sì, sono stati inviati. Vedi le specifiche W3C .

HTTPOnly ha lo scopo di mitigare attacchi come XSS, ma se un utente malintenzionato ha un XSS nel suo sito, non ha bisogno di un CSRF. Hai considerato il Pattern token crittografato ?

    
risposta data 16.06.2014 - 06:34
fonte

Leggi altre domande sui tag