PKCE: protezione dei client pubblici

Senza PKCE, le applicazioni mobili sono vulnerabili agli attacchi di intercettazione del codice di autorizzazione. Quando il server di autorizzazione reindirizza il codice di autorizzazione allo schema URI personalizzato registrato dall'app, ad esempio myapp://callback, qualsiasi applicazione dannosa sullo stesso dispositivo che registri lo stesso schema URI può intercettare il reindirizzamento e sottrarre il codice.

L'attacco funziona nel modo seguente: un'applicazione dannosa registra lo stesso schema URI personalizzato dell'applicazione legittima. Quando il server di autorizzazione reindirizza il codice a myapp://callback, il sistema operativo può presentare entrambe le app come gestori. Se l'utente seleziona l'app dannosa o il sistema operativo la sceglie come predefinita, l'attaccante riceve il codice di autorizzazione e può scambiarlo con i token senza conoscere il segreto del client.

PKCE (RFC 7636) aggiunge un segreto generato dinamicamente al flusso del codice di autorizzazione. Prima di avviare il flusso, il client genera una stringa crittograficamente casuale di 43-128 caratteri chiamata code verifier. Questa stringa è univoca per ogni richiesta di autorizzazione e non viene mai trasmessa prima della fase di scambio del token.

Il client calcola una code challenge a partire dal verifier: code_challenge = BASE64URL(SHA256(code_verifier)). L'utilizzo di SHA256 è il metodo richiesto da RFC 7636; il metodo "plain", che invia direttamente il verifier, non è consigliato. La code challenge è una trasformazione unidirezionale del verifier: conoscere la challenge non consente di ricavare il verifier.

La richiesta di autorizzazione include due parametri aggiuntivi: "code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256". Il server di autorizzazione memorizza la code challenge associandola al codice di autorizzazione emesso. In questa fase non viene trasmesso al server alcun segreto che potrebbe essere intercettato.

Durante lo scambio del token, tramite una richiesta POST all'endpoint dei token, il client include "code_verifier=ORIGINAL_RANDOM_STRING" insieme al codice di autorizzazione. Il server di autorizzazione calcola BASE64URL(SHA256(code_verifier)) e verifica che corrisponda alla code_challenge memorizzata. Solo il client legittimo che ha generato il verifier può superare questo controllo.

Se un attaccante intercetta il codice di autorizzazione, riceve solo il codice e la code challenge, che è pubblica. Per scambiare il codice con i token, deve fornire il code verifier. Poiché il verifier è stato generato dal client legittimo e non è stato trasmesso fino alla fase di scambio del token, che avviene in modo sicuro, l'attaccante non può calcolarlo né recuperarlo.

PKCE previene anche gli attacchi di iniezione del codice di autorizzazione, in cui un attaccante sostituisce nel reindirizzamento un codice valido con un codice rubato. Il code challenge associato al codice rubato non corrisponde al code verifier che il client della vittima presenterà, causando il fallimento dello scambio del token. PKCE fornisce una difesa in profondità contro più vettori di attacco contemporaneamente.

Sebbene RFC 7636 sia stato inizialmente descritto come una soluzione per i client pubblici (quelli privi di client secret), l'OAuth Security BCP e OAuth 2.1 richiedono PKCE per tutti i client, inclusi i client confidenziali con client secret. PKCE fornisce una protezione indipendente dall'autenticazione del client, risultando quindi vantaggioso in ogni caso.

OAuth 2.1 (draft-ietf-oauth-v2-1) riunisce in un unico documento le best practice di sicurezza dell'OAuth 2.0 Security BCP. Impone PKCE per tutti i flussi del codice di autorizzazione, depreca il flusso implicito e richiede la rotazione dei refresh token. PKCE costituisce di fatto il requisito di base obbligatorio per qualsiasi nuova implementazione di OAuth 2.0.

Implementare correttamente PKCE richiede di: usare un generatore di numeri casuali crittograficamente sicuro per il code verifier (almeno 32 byte casuali, quindi codificati in base64url), memorizzare il verifier in modo sicuro nel client (non nell'URL o nei log), usare il metodo S256 (non plain) e assicurarsi che il verifier venga eliminato dopo lo scambio del token. La maggior parte delle librerie OAuth moderne gestisce PKCE automaticamente.

In PKCE, qual è la relazione tra il code verifier e il code challenge?

PKCE (RFC 7636) previene l'intercettazione del codice di autorizzazione associando ogni codice a un code verifier generato dinamicamente e noto solo al client legittimo. Il verifier viene sottoposto ad hashing per produrre il code challenge (inviato pubblicamente). Lo scambio del token richiede il verifier originale. PKCE previene sia gli attacchi di intercettazione sia quelli di iniezione. OAuth 2.1 impone PKCE per tutti i flussi del codice di autorizzazione.