Qual è il vantaggio dell'oscilloscopio in OAuth2?

Question

Qual è il vantaggio dell'oscilloscopio in OAuth2?

#1 da (23 voti)
#2 da (3 voti)

17

In the question, substitute scope with state. Since there is an answer based on the wrong question, I'll let everything below as is. The answer is useful nonetheless.

Questa domanda si riferisce alla bozza corrente v30 di OAuth2 e GitHub's implementazione dello stesso.

Il "flusso di applicazioni Web" di GitHub è più o meno un'implementazione di Codice di autorizzazione Concedi come descritto nella specifica. Il client (l'applicazione Web) indirizza l'utente a una pagina speciale su GitHub che chiede se l'utente vuole consentire all'applicazione di accedere alle sue risorse. Se viene confermato, l'utente viene reindirizzato al client che quindi utilizza un codice temporaneo per recuperare il token OAuth per un utilizzo futuro.

Se il client ha fornito un parametro scope per la richiesta dell'utente a GitHub, anche il reindirizzamento contiene quel parametro. Se l'ambito è un segreto noto solo al client, il client può essere certo che nessun altro ha creato tale richiesta, cioè che l'utente non è stato vittima di un attacco CSRF.

Ma è davvero necessario?

Se scegliamo non per utilizzare un parametro scope e l'utente è effettivamente vittima di un attacco CSRF, lui o lei deve ancora accettare la domanda posta da GitHub se il client è autorizzato ad accedere alle informazioni dell'utente. Questo passaggio non può essere saltato. In effetti le specifiche dicono

[The] authorization server authenticates the resource owner and obtains an authorization decision (by asking the resource owner or by establishing approval via other means).

Se l'attaccante usa altre tecniche come il clickjacking per indurre l'utente ad accettare la richiesta, ritengo che tutte le scommesse siano comunque in ogni caso e l'oscilloscopio non proteggerà nemmeno l'utente.

In conclusione: contro quale minaccia l'ambito effettivamente protegge l'utente?

authentication oauth web-application

posta musiKk 22.07.2012 - 21:58

fonte

2 risposte

3

(la risposta si basa sul presupposto che OP intendeva parlare dello "stato" piuttosto che dello "scopo")

Non penso che il parametro "stato" sia inteso come una caratteristica di sicurezza. È solo un parametro che il consumatore può utilizzare per inserire alcuni dati che desidera recuperare dopo il completamento del flusso di autorizzazione.

Questo è utile nel caso in cui il consumatore non possa mantenere uno stato da solo (client stateless, non basati su sessioni, ecc.). Poiché il flusso di autorizzazione comporta il reindirizzamento del browser utente al provider, il client potrebbe, ad esempio, perdere traccia di quale pagina era attiva quando ha attivato il flusso di autenticazione (o cosa l'utente stava tentando di fare).

Passando tali informazioni nel parametro di stato, il client lo recupererà dopo il flusso di autorizzazione e potrà reindirizzare l'utente alla posizione appropriata, ad esempio.

risposta data 15.03.2014 - 02:00

fonte

Leggi altre domande sui tag authentication oauth web-application

In che modo un amministratore di rete blocca l'SSH inverso in azienda? Esporre i nomi dei campi del database in HTML

score 23 · Accepted Answer

Parametro di stato

Il parametro scope non viene utilizzato per proteggere la richiesta di autenticazione dagli attacchi CSRF (vedi sotto). Ma c'è un altro parametro chiamato "stato", che corrisponde alla tua descrizione.

[Chiedere all'utente]

This step cannot be skipped.

Ho paura, questa ipotesi non è corretta. È molto comune che all'utente venga richiesta l'autorizzazione solo quando utilizza per la prima volta un'applicazione client. Successivamente, il server memorizza l'applicazione client e concede l'accesso automaticamente.

Indeed the spec says

[The] authorization server authenticates the resource owner and obtains an authorization decision (by asking the resource owner or by establishing approval via other means).

Altri mezzi possono includere il fatto che l'applicazione è attendibile dal server (ad esempio di proprietà della stessa azienda) o che la decisione dell'utente è stata salvata.

Quindi, senza un parametro di stato, l'utente malintenzionato può ingannare un utente per accedere a un'applicazione, che è nota all'utente in linea di principio o generalmente attendibile dal server.

Parametro di ambito

Il parametro scope viene utilizzato per indica un elenco di autorizzazioni , richiesto dal client:

The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter.

Ad esempio, le autorizzazioni per un social network possono includere:

post_to_my_wall  send_notification  post_to_my_friends_wall  read_my_age

The value of the scope parameter is expressed as a list of space- delimited, case sensitive strings. The strings are defined by the authorization server.

Il server può fornire tutte le autorizzazioni richieste o un elenco modificato (ad esempio perché l'utente ha negato alcune autorizzazioni):

If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted.

Fonte: link