11. Security Considerations (Considerazioni sulla Sicurezza)

In DPoP, la prevenzione del replay del token su un endpoint diverso (vedere Sezione 2) è ottenuta attraverso l'autenticazione del server secondo [RFC6125] e il vincolo della prova DPoP a un certo URI e metodo HTTP. Tuttavia, DPoP ha una natura di protezione in qualche modo diversa rispetto ai metodi basati su TLS come OAuth Mutual TLS [RFC8705] o OAuth Token Binding [TOKEN-BINDING] (vedere anche le Sezioni 11.1 e 11.7). I meccanismi basati su TLS possono sfruttare una stretta integrazione tra il livello TLS e il livello applicativo per ottenere una forte integrità del messaggio, autenticità e protezione da replay.

11.1. Replay della Prova DPoP

Se un avversario riesce a impossessarsi di un JWT di prova DPoP, può riprodurre il token sullo stesso endpoint (l'endpoint e il metodo HTTP sono imposti tramite i claim corrispondenti nel JWT). Per limitare ciò, i server DEVONO accettare prove DPoP solo per un tempo limitato dopo la loro creazione (preferibilmente per un periodo relativamente breve nell'ordine di secondi o minuti).

Nel contesto dell'URI di destinazione, i server possono memorizzare il valore jti di ogni prova DPoP per la finestra temporale in cui il corrispondente JWT di prova DPoP verrebbe accettato, al fine di impedire che la stessa prova DPoP venga utilizzata più di una volta. Le richieste HTTP allo stesso URI per le quali il valore jti è stato visto in precedenza verrebbero rifiutate. Se applicato rigorosamente, tale controllo monouso (use-once) fornisce una protezione molto forte contro il replay della prova DPoP, ma non è sempre fattibile nella pratica, ad esempio quando più server dietro un singolo endpoint non condividono lo stato.

Per proteggersi dagli attacchi di esaurimento della memoria, i server che tracciano i valori jti DOVREBBERO rifiutare i JWT di prova DPoP con valori jti inutilmente grandi o memorizzare solo l'hash di essi.

Nota: per tenere conto della deriva dell'orologio, il server PUÒ accettare prove DPoP il cui orario iat è ragionevolmente nel prossimo futuro (nell'ordine di secondi o minuti). Poiché la deriva dell'orologio tra il server e il client può essere significativa, i server POSSONO limitare la durata delle prove DPoP utilizzando valori di nonce forniti dal server contenenti l'ora del server, invece di confrontare l'ora iat fornita dal client con l'ora del server. Un nonce creato in questo modo produrrà lo stesso risultato anche con una deriva dell'orologio arbitrariamente grande.

I nonce forniti dal server sono un modo efficace per ridurre ulteriormente le probabilità di successo del replay della prova DPoP. A differenza dei nonce crittografici, è accettabile che il client utilizzi lo stesso nonce più volte e che il server accetti lo stesso nonce più volte. Finché i valori jti vengono tracciati e i duplicati vengono rifiutati durante la validità del nonce, non vi è alcun rischio aggiuntivo di replay del token.

11.2. Pre-generazione della Prova DPoP

Un attaccante che controlla il client può pre-generare prove DPoP per qualsiasi momento nel futuro per un endpoint specifico scegliendo il valore iat nella prova DPoP firmata dalla chiave di prova di possesso. Si noti che uno di questi attaccanti è l'utente legittimo del client. Un utente potrebbe pre-generare prove DPoP, esfiltrarle dalla macchina che possiede la chiave di prova di possesso che le ha generate e copiarle su un'altra macchina che non possiede la chiave. Ad esempio, un impiegato di banca potrebbe pre-generare prove DPoP su un computer della banca e poi copiarle su un'altra macchina per utilizzarle in seguito, bypassando così i controlli audit della banca. Quando le prove DPoP possono essere pre-generate ed esfiltrate, ciò che viene effettivamente dimostrato nell'interazione del protocollo DPoP è il possesso della prova DPoP - e non il possesso della chiave di prova di possesso.

L'uso di un valore di nonce fornito dal server, imprevedibile per l'attaccante, impedisce questo attacco. Fornendo nuovi valori di nonce in momenti a sua scelta, il server può limitare la durata delle prove DPoP e impedire l'uso di prove DPoP pre-generate. Quando vengono utilizzati nonce forniti dal server, è il possesso della chiave di prova di possesso che viene dimostrato - e non solo il possesso della prova DPoP.

Il claim ath limita l'uso di prove DPoP pre-generate alla durata del token di accesso. Le distribuzioni che non utilizzano il meccanismo di nonce NON DOVREBBERO emettere token di accesso vincolati a DPoP a lunga durata e preferire token di accesso a breve durata e token di aggiornamento. Sebbene un attaccante possa pre-generare prove DPoP per utilizzare il token di aggiornamento per ottenere un nuovo token di accesso, non può in pratica pre-generare prove DPoP per utilizzare il token di accesso appena emesso.

11.3. Downgrade del Nonce DPoP

Quando è stato fornito un nonce DPoP a un client, il server NON DEVE accettare alcuna prova DPoP senza il claim nonce.

11.4. Codice Non Attendibile nel Contesto del Client

Se un avversario è in grado di eseguire codice nel contesto di esecuzione del client, la sicurezza di DPoP non è più garantita. Problemi comuni nelle applicazioni web che portano all'esecuzione di codice non attendibile sono attacchi XSS e Remote Code Inclusion.

Se la chiave privata utilizzata per DPoP è memorizzata in modo tale da non poter essere esportata (ad esempio, in un modulo di sicurezza hardware o software), l'attaccante non può rubare la chiave e utilizzarla per creare prove DPoP arbitrarie. Tuttavia, l'attaccante può creare nuove prove DPoP finché il client è online e utilizzare queste prove (insieme ai rispettivi token) sul dispositivo della vittima o su un dispositivo sotto il controllo dell'attaccante per inviare richieste arbitrarie che verranno accettate dal server.

Per inviare richieste anche quando il client è offline, l'attaccante può tentare di pre-calcolare prove DPoP utilizzando timestamp futuri ed esfiltrare queste prove con il token di accesso o di aggiornamento.

Un avversario potrebbe inoltre tentare di associare un token emesso da un endpoint del token a una coppia di chiavi sotto il controllo dell'attaccante. Un modo per ottenere ciò è modificare il codice esistente, ad esempio sostituendo le chiamate API crittografiche. Un altro modo è avviare una nuova autorizzazione tra il client (in un iframe) e il server di autorizzazione. Questa autorizzazione deve essere "silenziosa", ovvero non richiedere l'interazione dell'utente. Eseguendo codice nell'origine del client, l'attaccante può accedere al codice di autorizzazione risultante e utilizzarlo per associare la propria chiave DPoP al token restituito dall'endpoint del token. L'attaccante può quindi utilizzare il token risultante sul proprio dispositivo, anche se il client è offline.

È quindi estremamente importante proteggere il client dall'esecuzione di codice non attendibile, anche se viene utilizzato DPoP. Oltre alle pratiche di codifica sicure, la Content Security Policy (CSP) [W3C.CSP] può essere utilizzata come secondo livello di difesa contro XSS.

11.5. Scambio di JWT Firmati

I server che accettano JWT di prova DPoP firmati DEVONO verificare che il campo typ nelle intestazioni del JWT sia dpop+jwt per garantire che nessun JWT creato per altri scopi possa essere utilizzato da un attaccante.

11.6. Algoritmi di Firma

Gli implementatori DEVONO garantire che solo algoritmi di firma digitale asimmetrica ritenuti sicuri, come ES256, possano essere utilizzati per firmare prove DPoP. In particolare, l'algoritmo none NON DEVE essere consentito.

11.7. Integrità della Richiesta

DPoP non garantisce l'integrità del payload o delle intestazioni della richiesta. La prova DPoP contiene solo claim per l'URI HTTP e il metodo, ma non, ad esempio, il corpo del messaggio o le intestazioni generali della richiesta.

Questa è una decisione di progettazione intenzionale per mantenere DPoP semplice da usare, ma come descritto sopra, ciò rende DPoP vulnerabile agli attacchi di replay in cui l'attaccante è in grado di modificare il contenuto del messaggio e le intestazioni. In molte configurazioni, l'integrità e la riservatezza dei messaggi fornite da TLS sono sufficienti per fornire un buon livello di protezione.

Nota: sebbene le firme che coprono altre parti della richiesta siano fuori dallo scopo di questa specifica, informazioni aggiuntive da firmare possono essere aggiunte alla prova DPoP.

11.8. Token di Accesso e Vincolo della Chiave Pubblica

Il vincolo di un token di accesso a una chiave pubblica DPoP, specificato nella Sezione 6, utilizza un hash crittografico della rappresentazione JWK della chiave pubblica. Si basa sul fatto che la funzione di hash abbia una resistenza sufficiente alla seconda preimmagine in modo che sia computazionalmente impraticabile trovare o creare un'altra chiave che produca lo stesso valore di output hash. La funzione di hash SHA-256 è stata utilizzata perché soddisfa il requisito sopra menzionato ed è ampiamente disponibile.

Allo stesso modo, il vincolo della prova DPoP a un token di accesso utilizza l'hash di quel token di accesso come valore del claim ath nella prova DPoP (vedere Sezione 4.2). Ciò si basa sul fatto che il valore hash sia sufficientemente unico per identificare in modo affidabile il token di accesso. La resistenza alle collisioni di SHA-256 soddisfa questo requisito.

11.9. Codice di Autorizzazione e Vincolo della Chiave Pubblica

Il vincolo crittografico del codice di autorizzazione alla chiave pubblica DPoP è specificato nella Sezione 10. Questo vincolo impedisce attacchi in cui l'attaccante cattura il codice di autorizzazione e crea una prova DPoP utilizzando una chiave di prova di possesso diversa da quella detenuta dal client, e utilizza la prova DPoP per riscattare il codice di autorizzazione. Garantire end-to-end che possa essere utilizzata solo la chiave DPoP del client impedisce che i codici di autorizzazione catturati vengano esfiltrati e utilizzati altrove rispetto a dove è stato emesso il codice di autorizzazione.

I codici di autorizzazione possono essere raccolti da un attaccante, ad esempio, dai log in cui sono stati registrati i messaggi HTTP che li contengono. Anche se vengono fatti sforzi per rendere i codici di autorizzazione utilizzabili una sola volta, in pratica c'è spesso una finestra temporale in cui un attaccante può riprodurli. Ad esempio, quando il server di autorizzazione è implementato come un servizio replicato scalabile, alcune repliche potrebbero temporaneamente non avere ancora le informazioni necessarie per prevenire il replay. Il vincolo DPoP del codice di autorizzazione risolve tali problemi.

Se il server di autorizzazione non applica rigorosamente (o non può applicare) l'uso singolo per i codici di autorizzazione e un attaccante ha accesso al codice di autorizzazione (e al code_verifier se viene utilizzato PKCE), l'attaccante può creare una richiesta di token falsa, vincolando il token risultante a una chiave sotto il controllo dell'attaccante. Ad esempio, utilizzando XSS un attaccante può accedere al codice di autorizzazione e ai parametri PKCE. L'uso del parametro dpop_jkt impedisce questo attacco.

Il vincolo del codice di autorizzazione alla chiave pubblica DPoP utilizza l'impronta JWK della chiave pubblica, proprio come il vincolo del token di accesso. Si applicano le stesse considerazioni sull'impronta JWK.

11.10. Agilità dell'Algoritmo di Hash

Il membro del metodo di conferma jkt, il claim JWT ath e il parametro di richiesta di autorizzazione dpop_jkt definiti qui utilizzano tutti l'output della funzione di hash SHA-256 come valore. L'uso di una singola funzione di hash da parte di questa specifica è intenzionale per semplicità e per evitare potenziali problemi di sicurezza e interoperabilità dovuti a errori comuni di implementazione e distribuzione dei meccanismi di agilità dell'algoritmo parametrizzato. Tuttavia, l'uso di diverse funzioni di hash non è precluso se le circostanze dovessero cambiare in futuro rendendo SHA-256 insufficiente per i requisiti di questa specifica. Se si presentasse tale requisito, ci si aspetta che venga prodotta una breve specifica che aggiorna questa. Utilizzando l'output di una funzione di hash appropriata come valore, tale specifica definirebbe probabilmente un nuovo membro del metodo di conferma, un nuovo claim JWT e un nuovo parametro di richiesta di autorizzazione. Questi verrebbero utilizzati al posto o insieme alle rispettive controparti nelle stesse strutture di messaggio e flussi del protocollo più ampio definito da questa specifica.

11.11. Vincolo all'Identità del Client

Quando DPoP viene utilizzato con l'autenticazione del client, è vincolato all'autenticazione solo dal fatto che si verifica nello stesso tunnel TLS. Poiché la prova DPoP non è direttamente vincolata crittograficamente all'autenticazione, l'autenticazione o il messaggio DPoP potrebbero essere stati copiati nel tunnel. Sebbene l'inclusione dell'URI in DPoP attenui in parte questo rischio, una protezione migliore potrebbe essere fornita modificando il meccanismo di autenticazione per fornire un legame crittografico tra l'autenticazione e DPoP. Tuttavia, la modifica dei meccanismi di autenticazione o la fornitura di un legame aggiuntivo con l'autenticazione con altri mezzi esula dallo scopo di questa specifica.