Funzionerebbe per proteggere un cookie con un token OAuth?

4

Attualmente sto provando a configurare uno schema di autenticazione OAuth 2.0 per proteggere alcuni webservice stateless REST. Questi servizi gestiscono informazioni sensibili e il supporto OAuth è un requisito.


Il problema è che l'applicazione client è al 100% sul lato client (Angolare / Javascript), e non ci sono affatto sessioni utente, quindi sono alle prese con come gestire un token sul lato client senza esporlo a attaccanti.


Il piano è di fare qualcosa come:

  1. usa la concessione di utente / password per ottenere un token da IdentityServer (l'applicazione client è nostra e nessun client_secret viene lasciato in giro)
  2. memorizza il token in un cookie
  3. quando si effettua una richiesta, prendere il token dal cookie e utilizzarlo per firmare la richiesta
  4. quando scade il token, usa il refresh_token per ottenerne uno nuovo


Per inviare la richiesta, ho pensato che posso:

  • Invia il cookie HttpOnly come autenticazione, invece di firmare il token
  • Utilizza il cookie XSRF-TOKEN di Angular, che significa che il cookie deve solo essere accessibile a Javascript in esecuzione nel nostro dominio (anche se io credi che questo lascia ancora aperto agli attacchi XSS?)


I cookie saranno tutti impostati per garantire e inviare su HTTPS. Tuttavia, questo sembra ancora insicuro, dal momento che il token è ancora memorizzato come testo in chiaro. Anche il refresh_token sarà nel cookie. (Ho preso in considerazione anche l'archiviazione locale, ma a meno che non mi sia sfuggito qualcosa, non sembrava più sicuro ...)


Esiste un modo più sicuro per memorizzare un token oauth sul lato client?
O è questa sicurezza accettabile? Cosa mi manca qui?


Riferimento :

Protezione XSRF angolare: link $ http # cross-site-request-forgery-xsrf-protection

    
posta lv. 15.10.2015 - 14:10
fonte

1 risposta

2

Non ti stai preoccupando delle cose giuste

Protezione delle informazioni che si trovano sul client?

Non devi fare nulla una volta che le informazioni hanno raggiunto il tuo cliente (es .: il tuo browser) per proteggerlo. È possibile archiviare il token di accesso in un cookie, in un campo nascosto della pagina Web, nella cache locale html5 o semplicemente visibile direttamente nel mezzo della pagina e non cambia nulla (eccetto lo spallamento ...).

Preoccuparsi del token di accesso una volta che è sul client è come aprire il blocco note per scrivere la password e-mail e quindi preoccuparsi che un utente malintenzionato sia in grado di rubare tali informazioni da una posizione remota. Non succede A meno che il tuo computer non sia già compromesso, ma a questo punto l'hai già perso.

Dove ha senso preoccuparsi?

Di solito, le tue informazioni sono vulnerabili quando sono in transito. Nel caso di OAuth2 (flusso implicito), il token di accesso sarà in transito in due punti:

  • dal server di autorizzazione al browser
  • dal tuo browser al server delle risorse

Proteggere le informazioni mentre è in transito è facile come usare TLS ovunque. Che dovresti già fare visto che stai usando OAuth2 ed è richiesto dal protocollo.

Ora il vero problema

Il modo in cui intendi utilizzare OAuth2 non è probabilmente il modo in cui dovresti utilizzarlo.

Per capire perché probabilmente utilizzerai in modo improprio OAuth2, devi conoscere i flussi. OAuth2 definisce il flusso di autorizzazione 4

  • Codice di autorizzazione (solo buono ma ... continua a leggere)
  • Implicito (falso senso di sicurezza)
  • Credenziali password proprietario risorse (idea orribile)
  • Credenziali client (non applicabile al tuo caso)

Poiché utilizzi un client javascript, l'unico flusso che funziona per te è il flusso implicito e ora inizia i problemi.

Problemi di flusso implicito

Ce ne sono molti ma parliamo solo di quello più critico. Il token di accesso non è associato a un client specifico! dalla sezione delle specifiche 10.16:

For public clients using implicit flows, this specification does not provide any method for the client to determine what client an access token was issued to.

Questo apre le porte all'aggressore per impersonare te, il proprietario della risorsa, e quindi ottenere l'accesso al server delle risorse. Continuiamo a leggere la sezione 10.16:

A resource owner may willingly delegate access to a resource by granting an access token to an attacker's malicious client. This may be due to phishing or some other pretext. An attacker may also steal a token via some other mechanism. An attacker may then attempt to impersonate the resource owner by providing the access token to a legitimate public client.

In the implicit flow (response_type=token), the attacker can easily switch the token in the response from the authorization server, replacing the real access token with the one previously issued to the attacker.

Servers communicating with native applications that rely on being passed an access token in the back channel to identify the user of the client may be similarly compromised by an attacker creating a compromised application that can inject arbitrary stolen access tokens.

Any public client that makes the assumption that only the resource owner can present it with a valid access token for the resource is vulnerable to this type of attack.

Il primo attacco in realtà non è nemmeno un attacco ma piuttosto solo un "difetto" nel flusso implicito ...

Il prossimo attacco

Ora inizia i grandi problemi. Sembra che tu stia cercando di utilizzare il flusso implicito di OAuth2 come forma di autenticazione delegata dell'utente finale che non è stata pensata per fornire. Torna alla sezione delle specifiche 10.16

Authenticating resource owners to clients is out of scope for this specification. Any specification that uses the authorization process as a form of delegated end-user authentication to the client (e.g., third-party sign-in service) MUST NOT use the implicit flow without additional security mechanisms that would enable the client to determine if the access token was issued for its use (e.g., audience-restricting the access token).

A questo punto è quasi tutto per te.

Come si installa quell'attacco?

È piuttosto semplice. Supponiamo che il tuo servizio REST abbia richiesto un token di accesso da Facebook. Tutto ciò che un utente malintenzionato deve fare è ospitare un servizio, ad esempio StackOverflow, e richiedere un token di accesso da Facebook. Quando offri il token di accesso di Facebook a StackOverflow, StackOverflow (il nostro aggressore) può ora impersonare te con il tuo servizio REST.

Tutto ciò perché i token di accesso non sono associati a un client specifico.

Una soluzione

Non utilizzare il flusso implicito e utilizzare invece il flusso del codice di autorizzazione. Ciò significa che la tua app 100% lato client non dovrà più essere un'app 100% lato client.

Perché non stai utilizzando il server che serve il client angularjs all'utente per gestire il flusso OAuth2?

Riferimento: link

    
risposta data 15.10.2015 - 20:01
fonte

Leggi altre domande sui tag