Gestione della sessione dell'applicazione per pagina singola

2

Ho un'applicazione per pagina singola che è completamente HTML + JS + CSS (utilizzando framework come jQuery e AngularJS) e un'API lato server che utilizza ASP.NET WebApi.

La SPA viene servita in un server simile a un CDN e anche confezionata con Cordova per l'utilizzo negli smartphone.

L'API lato server ha molti metodi che richiedono autorizzazione e autenticazione, quindi devo accedere e passare un identificativo dal lato client in modo che il server possa sapere chi sono.

I problemi che sto affrontando:

  1. Una volta autenticato, dove dovrei memorizzare il token di accesso \ ID di sessione?

    al momento ho creato il mio metodo di autenticazione (non OAuth) che restituisce un ID di sessione, che il client inserisce in ogni successiva chiamata HTTP nell'intestazione Autorizzazione. Tuttavia, quando un utente decide di aggiornare la pagina, l'intestazione non è più disponibile. Le soluzioni devono salvare l'ID di sessione in un sessionStorage che potrebbe essere non sicuro (OWASP non lo consiglia, ma forse X-Frame-Options = SAMEORIGIN sarebbe sufficiente?) O usare un cookie HttpOnly per la gestione delle sessioni, che mi porta al prossimo punto:

  2. Se utilizzo i cookie, è necessario verificare la presenza di CSRF, ma se non lo sono? c'è qualche ragione per aggiungere un CSRF? è nello stesso ambito per l'ID di sessione.

  3. Ho il mio sistema utente e la gestione del gruppo che dispone di solidi controlli di accesso. C'è qualche vantaggio per me di usare OAuth e OpenID se ho già un filtro di autorizzazione funzionante che controlla ciò di cui ho bisogno, e non è basato su ruoli-stringa? (vale a dire ruoli="amministratori" ecc., ma completamente CanChangeResource (x))

Non sono riuscito a trovare domande simili che potrebbero rispondere ai miei problemi e apprezzerebbero una risposta informativa.

    
posta Albert 09.01.2016 - 16:18
fonte

1 risposta

2

Guardando le due opzioni che hai presentato, sessionStorage o HttpOnly cookie, c'è un trade-off. Hai ragione nel dire che se usi i cookie, hai bisogno di un token CSRF, e se usi sessionStorage e lo usi come fonte per l'intestazione, non lo fai.

Tuttavia, ciò che OWASP è interessato a sessionStorage è che una vulnerabilità XSS consente a un attacco di estrarre sessioni autenticate. Con un cookie HttpOnly, non è così. Data la prevalenza di XSS sul web oggi, questa è una minaccia da considerare seriamente.

Quindi, mentre sessionStorage sarebbe l'opzione più semplice, e potrebbe funzionare con poche modifiche al codice attualmente in uso, il cookie HttpOnly più un token anti-CSRF sarebbe l'approccio più sicuro. Devi decidere se vale lo sforzo extra per te, per la tua applicazione.

    
risposta data 09.01.2016 - 21:56
fonte

Leggi altre domande sui tag