MSAL in Chrome Extension: Secure Token Storage

user_197760 0
Viewed 443

We've made a Chrome extension that sits within an iFrame to prevent XSS in case of a visit to an evil.com. The purpose of the extension is to serve relevant data from a web service pertaining to the page being visited. The app authenticates via MSAL and currently stores the token in sessionStorage. Each tab requires its own login, which is a poor experience, so we're moving to use localStorage. I've found links suggesting relative security is better with sessionStorage, though the root issues seem to apply to both. What are best practices to achieve our use case, and what is the attack surface? Thank you.

-- EDITED 10/22 --

Adding diagram below to help clarify. Specific questions re MSAL.js for the given the scenario:

  • Is our iframed app, or its localStorage-cached token vulnerable to anything running in the host websites
  • Does using sessionStorage vs localStorage on MSAL impose any security concerns? (localStorage is very important to our UX as with sessionStorage visiting any website / new tab would start a new login process)
  • Are there any CSPs that we should look into incorporating in our MSAL app that would reinforce security further? enter image description here
msal.js msal local-storage xss
1 Answers

Storing tokens in browser storage is only one part of the story. Azure AD takes additional steps for increasing security. For instance, tokens assigned to SPAs have a 1hr only lifespan. Then there are a number of features for eliminating replay attacks, such as signing key rotation, multi-factor authentication, continuous access evaluation and etc. The API here also validates access tokens before granting access. Ultimately, its a tradeoff between more security and better user experience. For example, session storage is more secure, but local storage gives you single-sign on between tabs. MSAL.js has an in-memory token storage option, and there is work on providing a secure storage option. In general, SPAs are not meant to be dealing with critical data access. In such cases you might want to use a web app or a SPA using on-behalf-of flow, for instance. A correctly implemented browsers (a.k.a. User Agent) will not allow the iframe contents to leak outside the iframe. If the host document (one containing the element) has suitable styling and hints the iframe contains untrusted content, there's no problem. Modulo real vulnerabilities in the browser, of course. In short, an is about as safe as a <a href>.

user_145924310
Related