【PoC編】XSSへの耐性においてブラウザのメモリ空間方式はLocal Storage方式より安全か？ - Flatt Security Blog

はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事は、Auth0のアクセストークンの保存方法について解説した前回の記事の補足となる記事です。前回の記事の要旨をざっくりまとめると以下のようなものでした。 Auth0はデフォルトではアクセストークンをブラウザのメモリ空間上にのみ保存するin-memory方式であり、XSSへの耐性のなさ等の理由でlocalStorageで保存することを推奨していない しかし、XSSでアクセストークンを奪取できるのはin-memory方式でも同じのはず(検証は行いませんでした)。localStorage方式を過度に忌避する必要はないのではないか なお、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用

[uhavetwocows]

書きました！XSSがあるとフロントのコードと同じ権限で大抵のことができます、という話です

[hinaloe]

in-memory，すくなくともリロードして機能する、JSコードはパブリック、SPAで利用する、の前提が揃ってる時点でXSSできればそりゃ再現可能だわなというはなしで…？

[NOV1975]

元記事については僕も徳丸さんも「XSS脆弱性があれば全部一緒だよね」とコメントしていたが、ちゃんと検証してくれる人がいるとありがたいですね。とにかくまずXSS対策ですね。

[ockeghem]

PoC出ました。結局、XSSの脅威に対しては、HttpOnlyなCookie、localStorage、Auth0流のin-memory方式のいずれも大差ないという結論でよいと思います。

[blog0x003f]

みんな本当に理解してて前のコメントにあった記事が読まれてたのかな

[unarist]

保存場所の比較だけで言えばトークンをローカル変数に閉じ込めるのはマシではあるが、実際には保存場所以外の隙からXSSで刺されたりするよ、と。

[hdampty7]

HttpOnlyのセッションクッキー方式なら認証そのものを取られることはない。まあ、ページの内容とかはXSSがあれば抜かれちゃいますけどね。穴があれば結局同じかなぁ。

[trkbt10]

localStorageにもっとセキュアなアクセス方法があれば何も考えずに突っ込めるのに

[getcha]

前の記事は「あとで読む」して読んでいない。そしてこの記事も「あとで読む」にした。

[ryousanngata]

メモリ上の変数は参照できないがpostMessageでやりとりしているのを傍受するだけで見れる、と。iframe版ではなくWebWorkerだとworkerの変数が辿れないと似たことができないので少し難しくなるはず（Auth0Clientの扱いによる）

[azzr]

だよねぇ。XSSされたら負けなので、された後のmitigationをするより、XSSされないこと自体に注力すべき。CSPとかSRIとかsandbox iframeとか、できることはたくさんあるんだし。