2. Objectives (Obiettivi)
2. Objectives (Obiettivi)
L'obiettivo principale di DPoP è prevenire l'uso non autorizzato o illegittimo di token di accesso trapelati o rubati da parte di soggetti non autorizzati, vincolando un token a una chiave pubblica al momento dell'emissione e richiedendo al client di dimostrare il possesso della chiave privata corrispondente quando utilizza il token. Ciò vincola il legittimo mittente del token a essere solo la parte in possesso della chiave privata, dando al server che riceve il token la garanzia che il mittente è legittimamente autorizzato a utilizzarlo.
I token di accesso vincolati al mittente tramite DPoP contrastano quindi con i tipici token Bearer, che possono essere utilizzati da qualsiasi parte in possesso di tale token. Sebbene in genere siano in atto protezioni per prevenire la divulgazione involontaria dei token Bearer, si sono verificati vettori di perdita imprevisti a causa di vulnerabilità e problemi di implementazione in altri livelli del protocollo o dello stack software (ad esempio, Compression Ratio Info-leak Made Easy (CRIME) [CRIME], Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) [BREACH], Heartbleed [Heartbleed] e il bug del parser Cloudflare [Cloudbleed]). Anche le implementazioni OAuth stesse hanno subito numerosi attacchi di furto di token resi pubblici ([GitHub.Tokens] è solo un esempio notevole). DPoP fornisce un meccanismo generale di difesa in profondità per proteggersi dalle conseguenze di tali perdite accidentali di token. DPoP non è tuttavia un sostituto del trasporto sicuro e deve essere sempre utilizzato in combinazione con HTTPS.
La natura delle tipiche interazioni del protocollo OAuth richiede al client di rivelare il token di accesso alla risorsa protetta a cui sta accedendo. Il modello dell'attaccante in [SECURITY-TOPICS] descrive il caso in cui la risorsa protetta è contraffatta, dannosa o compromessa e utilizza il token ricevuto su altre risorse protette per ottenere un accesso non autorizzato. I token di accesso limitati a un'audience (ad esempio, utilizzando il claim aud di un JWT [RFC7519]) possono prevenire tale uso improprio. In pratica, tuttavia, ciò si è rivelato troppo oneroso per molte distribuzioni (nonostante estensioni come [RFC8707]). Vincolare al mittente i token di accesso è un meccanismo più robusto e diretto per prevenire il replay di tali token su diversi endpoint, con DPoP che è un mezzo praticabile a livello applicativo.
I client OAuth basati su browser portano ulteriori considerazioni riguardanti la protezione dei token a causa del potenziale rischio di Cross-Site Scripting (XSS). L'attacco XSS più diretto è dove l'attaccante ruba il token e lo utilizza in modo completamente indipendente dal client legittimo. I token di accesso rubati vengono utilizzati per accedere alle risorse protette e i token di aggiornamento rubati vengono utilizzati per ottenere nuovi token di accesso. Se la chiave privata è archiviata in modo tale da non poter essere esportata (come abilitato da [W3C.WebCryptoAPI]), DPoP rende i token rubati inutili da soli.
Una vulnerabilità XSS consente inoltre a un attaccante di eseguire codice nel contesto dell'applicazione client basata su browser e utilizzare il token in modo dannoso indirettamente tramite il client. Questo contesto di esecuzione ha accesso alle chiavi di firma; pertanto, può produrre prove DPoP da utilizzare in combinazione con il token. Si ritiene che probabilmente non esista una difesa praticabile a questo livello applicativo contro questa minaccia, a parte la prevenzione generale XSS; pertanto, ciò è considerato fuori dallo scopo di DPoP.
Il codice XSS dannoso in esecuzione nel contesto dell'applicazione client basata su browser può anche creare prove DPoP con valori di timestamp futuri ed esfiltrarli con i token. Questi artefatti rubati possono quindi essere utilizzati indipendentemente dall'applicazione client per accedere alle risorse protette. Per prevenire ciò, un server può facoltativamente richiedere al client di includere nella prova un valore scelto dal server (un nonce) imprevedibile per l'attaccante. In assenza di un nonce opzionale, l'impatto delle prove DPoP pre-calcolate è limitato dal vincolo della prova al token di accesso quando si accede alle risorse protette. Poiché non è realisticamente possibile creare una prova che copra un token di accesso che non esiste ancora, un token di accesso ottenuto utilizzando un token di aggiornamento rubato e una prova pre-calcolata non sarà utilizzabile.
Ulteriori considerazioni sulla sicurezza sono discusse nella Sezione 11.