Questo è il problema che stai cercando di prevenire convalidando il token :
As a simplified example, imagine there are two apps: (1) FileStore, a
legitimate file storage app, and (2) EvilApp. Both apps use Google's
authentication process for client-side apps. Alice is an innocent end
user, and her Google user ID is XYZ.
- Alice signs into FileStore using Google.
- After the auth process, FileStore creates an account for Alice and associates it with Google user ID XYZ.
- Alice uploads some files to her FileStore account. So far everything is fine.
- Later, Alice signs into EvilApp, which offers games that look kind of fun.
- As a result, EvilApp gains an access token that is associated with Google user ID XYZ.
- The owner of EvilApp can now construct the redirect URI for FileStore, inserting the access token it was issued for Alice's Google
account.
- The attacker connects to FileStore, which will take the access token and check with Google to see what user it is for. Google will
say that it is user XYZ.
- FileStore will give the attacker access to Alice's files because the attacker has an access token for Google user XYZ.
FileStore's mistake was not verifying with Google that the access
token it was given was truly issued to FileStore; the token was really
issued to EvilApp.
I believe proper use of the OAuth "state" parameter can also prevent
this vulnerability. "Proper use" being cryptographically and securely
binding the state parameter value to the current browser session. This
can be done by hashing a combination of the session ID and a nonce
(I'm not sure if including the nonce is necessary).
I have two questions:
My primary question is: Can proper use of the OAuth "state" parameter,
along with using TLS with server certificate validation, mitigate the
confused deputy problem, without validating the audience of the access
token, for some definition of "proper use" that mitigates cross site
request forgery?
No, devi convalidare audience , non stato, come da questo articolo :
Some people believe that using the state parameter in OAuth protects
against token substitution. The only binding a browser cookie to state
protects against is Cross Site Scripting [think they mean CSRF]. In the attack I am
proposing the client generates a legitimate request to a bad user
agent that captures it and provides a response that includes state
unchanged from the request. Their is nothing in the OAuth client-side
flow that proves the issuer you sent the request to through the
browser ever received it and is the one responding. Only the
access_token parameter is generated by the Authorization server, all
the other parameters are dropped or echoed back. The client has no
way to tell who the authorization server thought it was issuing that
access_token to.
Immagina che un utente malintenzionato faccia clic su un pulsante sulla tua app per consentirgli di accedere al suo account Google al fine di convalidare la sua identità (ad esempio l'autenticazione). Tuttavia, invece di seguire il reindirizzamento, invece, afferra il valore dello stato e lo memorizza da qualche parte. Poi riceve un token dalla sua app dannosa e poi lo riproduce sul redirect_uri , sostituendo il state che ha catturato a se stessa.
L'app autentica l'utente come quello che ha dato accesso alla sua app dannosa. Convalidare il pubblico è invece l'approccio sicuro perché viene controllato da Google quando si convalida il token sul lato server.
My secondary question is: Is cross site request forgery a type of confused deputy problem? And if "yes", then isn't the answer to my primary question also "yes" necessarily?
Sì, CSRF è un altro tipo di problema con i confusi.
Per questo motivo è possibile utilizzare
state , in quanto ciò confermerebbe che una parte malintenzionata non ha allettato un utente al proprio sito e reindirizzato al proprio endpoint per autorizzare l'account dell'attaccante contro la propria app. Ad esempio, se la tua app copia il contenuto da sé e si sincronizza con un account Google, l'utente malintenzionato potrebbe reindirizzare l'utente al tuo endpoint, dovresti controllare sul lato server che il token corrisponde e quindi iniziare a sincronizzare il tuo contenuto con l'account Google: dato che questo è l'account dell'attaccante, ora hanno accesso ai file dell'utente. Quindi, perché controllare state è una buona soluzione per questo.