Is it safe to use a secure, HTTPOnly, SameSite cookie (say, with a short timeout) to store the state parameter's value?
Puoi renderlo sicuro.
Supponendo che tu stia scrivendo software sul lato server (presumo che tu lo faccia, dal momento che hai menzionato l'impostazione dell'opzione HTTPOnly per il cookie): criptare il parametro state sul server e memorizzare il valore crittografato nel cookie. (Dettagli: assicurati di utilizzare un algoritmo di crittografia sicuro con un iv casuale e non utilizzare la modalità ecb). Assicurati di mantenere la chiave di crittografia protetta sul server.
Perché crittografare il cookie?
Devi crittografare il valore dello stato (o l'intero cookie) per due motivi:
-
In linea di principio: alle persone in sicurezza piace stratificare le loro misure di sicurezza.
Se uno fallisce, l'altro ti proteggerà ancora. Anche se
proteggi il tuo traffico con SSL, la crittografia SSL potrebbe essere compromessa. Ad esempio, dove lavoro, abbiamo un firewall che controlla i contenuti che esegue MITM su SSL, quindi interrompe la sicurezza della connessione in base alla progettazione. (Questa è una pessima idea, tutto sommato, ma credo che sia abbastanza comune - e significa che non puoi contare su SSL che protegge la connessione dal tuo server ai tuoi clienti.
-
Per proteggere il valore dello stato dal client (user-agent). Se sul tuo client è presente malware, non desideri esporre il valore dello stato ad esso. Potrebbe essere rubato. Se il valore dello stato è crittografato, il software client non ha accesso ad esso, il che è positivo.
È sicuro?
Questo è sicuro tanto quanto memorizzare un id di sessione nel cookie e quindi utilizzare l'id di sessione come indice in una tabella di database lato server, poiché né il browser né il javascript malevolo siedono nel browser né nessun altro vede altro di una stringa opaca e casuale nel tuo cookie criptato, e se si confondono con esso in alcun modo, non decodificherà il valore dello stato originale, il che farà fallire la verifica dello stato. Ma potresti voler aggiungere un MAC (codice di autenticazione dei messaggi) e toccare solo il valore dello stato crittografato dal cookie quando il MAC esegue il check out per proteggere i contenuti dei cookie dall'intromissione.
Elaborazione javascript locale nel browser vs elaborazione lato server
Se stai scrivendo browser javascript che fa richieste oauth, devi essere molto attento (ma la sicurezza del browser javascript è fondamentalmente infranta, se hai un'applicazione browser javascript fai richieste oauth, dubito che tu possa renderlo davvero sicuro - puoi renderlo ragionevolmente sicuro, ma probabilmente non puoi difenderti contro un determinato avversario.
La convalida del parametro stato è sufficiente?
Would validating the value in the cookie with the value in the state parameter be sufficient to verify the validity of the request?
Se la convalida dello stato è sufficiente per convalidare la richiesta oauth (risposta?) dipende da quale flusso si sta utilizzando e in quale fase del protocollo si è.
Ad esempio, se stai recuperando un token ID jwt, in quasi tutti gli scenari devi verificare il token ID per assicurarti che sia valido e significato per te (puoi farlo tu stesso o inviarlo a un endpoint di verifica. Un token jwt id è firmato digitalmente e devi assicurarti che la firma sia a posto, il pubblico e il tuo id cliente corrispondano, il token non sia scaduto ecc.).
Lo stesso vale per i token di accesso: se, ad esempio, non si verifica il pubblico del token di accesso, potrebbero verificarsi problemi (ad esempio il token di accesso potrebbe essere destinato a un altro client ...)
Ci sono alcuni casi in cui non devono verificare i token. Quando utilizzi l'open id connect per ottenere un token ID da un provider di identità e non instradi la richiesta attraverso il browser e recuperi il token ID dal tuo provider di identità tramite richiesta lato server, allora penso che tu possa fidati del token ID senza verifica. Tuttavia, continuo a verificare sempre, solo per essere sicuro di non inciampare sulla mia intelligenza; -)