Nel contesto di un'applicazione web ... i token sensibili, come quelli utilizzati per le sessioni, l'autenticazione e / o l'autorizzazione, devono essere memorizzati in localStorage o un cookie HTTPOnly; o sono entrambi approcci accettabili in circostanze diverse?

Ai fini di questa domanda, supponiamo che il token in questione, qualunque sia la forma che potrebbe assumere, potrebbe essere sfruttato per impersonare l'utente / dirottare la propria sessione se fosse divulgata ad un avversario.

Sfondo

La mia personale comprensione / convinzione è sempre stata che i cookie HTTPOnly sono la scelta di sicurezza ottimale in queste situazioni, a causa dei rischi associati allo scripting cross-site. Il cheat HTML5 di OWASP consiglia lo stesso.

Cookie Pro HTTPOnly:

• Un attacco di scripting cross-site riuscito non può accedere al token.
• Le estensioni del browser dannose non possono accedere al token.
• Lo sfruttamento del token è più difficile per l'utente malintenzionato, che deve eseguire XMLHttpRequests tramite il browser della vittima (quando il token verrà automaticamente allegato alla richiesta).

Pro localStorage / sessionStorage:

• Gli attacchi di contraffazione di richieste tra siti sono completamente impediti.

Per me, entrambi gli attacchi XSS e CSRF sono complessi da proteggere e, di conseguenza, trarrebbero vantaggio da più livelli di controlli di sicurezza. Cioè Vedo che team di sviluppo esperti producono ancora applicazioni con occasionali bug XSS e / o CSRF: la protezione da questi problemi su scala universale e su vasta scala può essere difficile.

localStorage sembra risolvere completamente CSRF, ma lascia il token accessibile a JavaScript dannoso in caso di bug XSS. I cookie HTTPonly parzialmente mitigano l'XSS ma introducono CSRF come un nuovo vettore di attacco, che deve essere protetto tramite i propri controlli. L'impatto di un attacco XSS è potenzialmente più alto di CSRF.