È sicuro memorizzare i token bearer in un iframe e / o passarli alla finestra padre?

Question

È sicuro memorizzare i token bearer in un iframe e / o passarli alla finestra padre?

#1 da (1 voti)

3

Non sono un esperto di sicurezza, quindi spero che alcuni di voi siano in grado di dirmi se ci sono dei difetti nella progettazione della sicurezza per la mia app web. Spero di essere in grado di spiegarlo abbastanza chiaramente da farmi capire meglio.

Ho un sito Web che effettua chiamate alla mia API. Entrambi utilizzano SSL e sono ospitati in Azure, ma hanno domini / server diversi. Sto anche usando i token bearer di ASP .Net Identity 2.0 e OAuth, con una scadenza di 30 giorni, per tracciare se un utente è "loggato" o meno.

Gli utenti possono accedere tramite il sito Web principale o utilizzando un widget che può essere aggiunto a QUALSIASI sito di terze parti.

Per mantenere le cose sicure, il widget crea un iframe che punta a una pagina sul mio server API e tutte le funzionalità, come l'elaborazione di login e transazioni, si svolgono all'interno di questo iframe.

La pagina padre usa postMessage per comunicare con l'iframe quando qualcosa deve accadere, ma per evitare che qualcosa nella pagina padre ottenga l'accesso a quel token, esiste solo nella memoria locale / sessione dell'iframe e non viene mai comunicato back up lo stack.

Finora tutto sembra funzionare come previsto, ma mi sono imbattuto in uno scenario in cui ora devo comunicare il token al genitore per il codice in esecuzione sul mio sito web. Tuttavia, sono riluttante a farlo, in quanto potenzialmente crea un buco di sicurezza.

Qualcuno ha qualche idea sul fatto che questo sia un rischio accettabile per il controllo del codice I, o se ci sono problemi con l'approccio generale che ho preso?

oauth web-application iframe

posta Joshua Barker 27.06.2015 - 08:38

fonte

1 risposta

Leggi altre domande sui tag oauth web-application iframe

Oauth2 come funziona (client Android) Unisci una seconda coppia di chiavi OpenPGP nell'ID utente dell'altra chiave

score 1 · Answer 1

Non dovresti permettere che la tua pagina di autenticazione / autorizzazione sia incorporata in un IFrame, perché in questo modo non puoi impedire gli attacchi di clickjacking.

Da RCF6749, Sezione 10.13 "Clickjacking" :

To prevent this form of attack, native applications SHOULD use external browsers instead of embedding browsers within the application when requesting end-user authorization. For most newer browsers, avoidance of iframes can be enforced by the authorization server using the (non-standard) "x-frame-options" header. This header can have two values, "deny" and "sameorigin", which will block any framing, or framing by sites with a different origin, respectively. For older browsers, JavaScript frame-busting techniques can be used but may not be effective in all browsers.

Non che il pericolo qui non sia che qualcuno sovrappone un pulsante invisibile sopra l'iframe del tuo sito, ma viceversa: un utente malintenzionato crea un pulsante dall'aspetto simile a "Mostra simpatici gattini" e sovrappone il tuo "Autorizza questa app" per accedere a tutti i miei dati "frame in cima a quello. Quando l'utente fa clic sul pulsante "gattini", in realtà concede l'accesso al suo account all'autore dell'attacco. L'unico modo per aggirare è quello di non consentire il flusso in un iframe. O semplicemente assumersi il rischio e conviverci.

A partire da questo, dovresti stare attento con i gettoni al portatore: chi li detiene ha un'autorizzazione e viene inviato tramite il filo per ogni operazione. Una vita di 30 giorni per qualcosa come access_token è una cattiva idea.

Per la tua app puoi risolverlo a tuo piacimento, oauth2 offre il flusso di "credenziali del proprietario delle risorse" che è una buona opzione per IMHO. Ma non hai davvero bisogno di oauth qui.

Per i siti web di terze parti dovresti utilizzare un flusso sul lato server con% di vita breveaccess_tokens e con% di vita di lunga durata che richiedono l'autenticazione del client (quando possibile)

Per i consumatori lato utente-utente (app native) dovresti usare un flusso lato client con token di breve durata e prendere precauzioni aggiuntive. O usa qualcosa di diverso da oauth, oauth è molto incentrato sul web.

PS : vorrei anche sottolineare che il commento di @HTLee sulla domanda è errato:

For anyone considering doing this - it is best to avoid the bearer token approach. If you can make use of the authorization code grant flow, the token is stored server side, and is never exposed to the browser (plus for security). With a bearer token approach the token needs to be exposed to the browser

"Portatore" è una proprietà del token che significa "chiunque sia in possesso di questa stringa è autorizzato". Non è legato a un flusso particolare e infatti il flusso del "codice di autorizzazione" produrrà un token al portatore chiamato refresh_tokens (e facoltativamente un altro chiamato access_token ).

L'alternativa ai token "bearer" è un token MAC, che non viene mai inviato via cavo. Le specifiche per i token MAC in oauth2 non sono ancora state testate.

Questo è ciò che post di Eran Hammer riguardava e è solo tangente alla domanda dell'OP.