Che cosa protegge effettivamente PKCE?

Question

Che cosa protegge effettivamente PKCE?

#1 da (6 voti)
#2 da (5 voti)

7

Sto cercando di capire come PKCE funziona in un'app mobile e c'è qualcosa che non abbastanza comprensibile.

Quindi, da ciò che posso raccogliere l'app client crea una stringa crittograficamente protetta casualmente nota come verificatore del codice. Questo è quindi memorizzato. Da questo, l'app genera quindi una sfida di codice. La verifica del codice viene quindi inviata in una richiesta API a un server insieme a come è stata generata la richiesta, ad es. S256 o semplice. Il server memorizza questa richiesta insieme a un codice_autorizzazione appropriato per la richiesta in questione.

Quando il client tenta di scambiare il codice per un token di accesso, invia anche il verificatore di codice originale nella richiesta. Il server recupera quindi la sfida memorizzata e il metodo utilizzato originariamente per generarlo per questo particolare codice e genera l'hash equivalente s256 / plain e li confronta. Se corrispondono, restituisce un token di accesso.

Quello che non capisco è come questo dovrebbe sostituire un segreto in un'app client? Sicuramente, se volessi fare una parodia di questo, prenderai il client_id normalmente e genererai il tuo verificatore di codice e la tua sfida e sarai nella stessa posizione come se PKCE non fosse richiesto in primo luogo. Che cosa sta effettivamente cercando di risolvere qui PKCE se l'idea originale fosse che si tratta fondamentalmente di un "segreto dinamico"? La mia ipotesi è che ci sia solo se qualcuno capita di "ascoltare" quando viene restituito auth_code , ma se stai usando di nuovo SSL è necessario? Viene addebitato come sostituto del fatto che non si dovrebbe archiviare un segreto in un'app pubblica, ma il fatto che il cliente sia responsabile della generazione piuttosto che di un server sembra che non ci stia effettivamente aiutando.

api rest client oauth2

posta TommyBs 14.12.2017 - 12:56

fonte

2 risposte

5

Il motivo per cui PKCE è importante è che sul SO mobile, il sistema operativo consente alle app di registrarsi per gestire gli URI di reindirizzamento in modo che un'app dannosa possa registrarsi e ricevere reindirizzamenti con il codice di autorizzazione per app legittime. Questo è noto come un attacco di intercettazione del codice di autorizzazione.

Attacco di intercettazione del codice di autorizzazione

Questo è descritto da WSO2 qui:

Since multiple applications can be registered as a handler for the specific redirect URI, the vulnerability of this flow, is that a malicious client could also register itself as a handler for the same URI scheme that a legitimate application handles. If this happens, it is a possibility that the operating system will parse the URI to the malicious client. The flow of this attack is illustrated in the following diagram.

In some operating systems such as Android, in step 5 of the flow, the user is prompted to select the application to handle the redirect URI before it is parsed using a "Complete Action Using" activity. This may avoid a malicious application from handling it, as the user can identify and select the legitimate application. However, some operating systems (such as iOS) do not have any such scheme.

Rif: link

Per capirlo meglio, ecco uno schema e una discussione di OpenID. Puoi vedere che il browser di sistema mobile ha la responsabilità di ricevere l'URI di reindirizzamento e indirizzarlo all'app corretta.

Rif: link

Tuttavia, poiché i sistemi operativi mobili possono consentire a molte app di registrarsi per lo stesso URI di reindirizzamento, un'app dannosa può registrarsi e ricevere un codice di autorizzazione legittimo come mostrato in questo diagramma, anche da WSO2:

Mitigazione dell'attacco di PKCE

PKCE lo mitiga richiedendo una conoscenza condivisa tra l'app che avvia la richiesta OAuth 2.0 (codice di autorizzazione della richiesta) e quella che scambia il codice di autenticazione per il token. Nel caso di un attacco di intercettazione del codice di autenticazione, l'app dannosa non ha il verificatore per completare lo scambio di token.

risposta data 02.06.2018 - 17:55

fonte

Leggi altre domande sui tag api rest client oauth2

Data di scadenza / data di scadenza CSR Perché Google utilizza i tentativi di inclusione dei file locali e di attraversamento delle directory sul mio sito

score 6 · Accepted Answer

Questo write-up Okta ha su questo il soggetto spiega questo piuttosto bene IMHO.

Credo che sia dovuto al fatto che PKCE è destinato ad applicazioni native (ad esempio Android, iOS, UWP, Electron, ecc.) in cui si lascia il contesto di sicurezza dell'applicazione e si accede al browser per l'autenticazione e si basa sul ritorno sicuro a la tua applicazione dal browser. Non hai necessariamente TLS sul reindirizzamento verso la tua applicazione (nel caso di schemi personalizzati, stai facendo affidamento sul sistema operativo per riportare la risposta alla tua applicazione) quindi, nel caso in cui il tuo codice di autorizzazione vada da qualche parte malintenzionato, il destinatario l'app non sarebbe in grado di ottenere un token di accesso senza il segreto dinamico.

I pregi di un segreto dinamico su un client pubblico sono evidenti qui - e l'ipotesi per PKCE è che non è difficile intercettare la risposta dal browser alla tua applicazione.