おーい磯野ー，Local StorageにJWT保存しようぜ！

ある日，HTML5のLocal Storageを使ってはいけない がバズっていた．
この記事でテーマになっていることの１つに「Local StorageにJWTを保存してはいけない」というものがある．
しかし，いろいろ考えた結果「そうでもないんじゃないか」という仮定に至ったのでここに残しておく．

先の記事では，「Local StorageにJWTを保存してはいけない」の根拠として「XSSが発生した時，攻撃者がLocal Storageに保存したJWTを盗むことが出来てしまう」といったセキュリティ上の懸念事項が挙げられていた．

これに対し，クッキーを用いたセッションベースの認証では，セッションIDをクッキーに保存する．クッキーにHttpOnlyフラグをつけておけば，JavaScriptからはアクセスできず，XSSが発生しても攻撃者はセッションIDを読み取ることが出来ない．

一見すると，これはLocal Storageを使う場合に発生する懸念事項をクリアしているように見えた．
しかしよく考えると，攻撃者にとって真に重要なのは認証トークンでは無く，認証トークンを使って何をするか，ということのはずだ．
このことについては，Why HttpOnly Won't Protect Youでも述べられている．
該当部分について引用する．

It is highly unlikely that the attacker will wait all the time just to get a session which could be invalidated a couple of moments later when the user clicks on the logout button. Remember, session hijacking is possible because concurrent sessions are possible.
The only and most effective way to attack when having a XSS hole is to launch an attack right on place when the payload is evaluated. If the attacker needs to transfer funds or obtain sensitive information, she most probably will use the XMLHttpRequest object in the background, to automate the entire process.

訳:
ユーザがログアウトボタンを押すと，すぐに無効になるようなセッションを取得するために，攻撃者が常に待っているとは考えづらい．
セッションハイジャックが可能なのは，同時セッションが可能であるからだ．
XSSの穴がある時，攻撃を行う唯一の，そしてもっとも効果的な方法は，ペイロードが評価された時にその場で攻撃を行うことだ．
もし攻撃者が送金や機密情報を取得する必要がある場合，彼女はおそらくプロセス全体を自動化するために，バックグラウンドでXMLHttpRequestを使うだろう．
訳注: 「同時セッション」について，攻撃対象と並行してセッションをハイジャックする必要がある，ということだと思う．

つまり，ペイロードが評価されたと同時に攻撃する方が効率的だし，この場合クッキーは送信されればよく，読む必要すら無い．このことを踏まえると，XSSが発生した場合，クッキーのHttpOnly属性が効果的だとも思えない．
「機密情報はクッキーに」というような単純な問題ではないのではないだろうか．

この記事は，私がScrapboxに投稿した おーい磯野ー，Local StorageにJWT保存しようぜ！ を試験的にZennに公開しているものです．