はじめに
Nuxt3が正式にリリースされてから約2年経ちましたが、そろそろ業務で扱うのにも慣れてきた頃ではないでしょうか？
また、昨今情報漏洩に関する関心が高まっているなかで、CORSやCSRF対策を見直している方もいるかも知れませんが、Nuxt(Vue)はSSRを扱っているなら知らなかったでは済まされない情報漏洩リスクであるクロスリクエスト状態汚染(cross-request state pollution)というものがあります。
この記事では、どのような場合にクロスリクエスト状態汚染が起きるのか、そして防げるのかを解説していきます。
※タイトルでは「情報漏洩をさせる方法」と書きましたが、情報漏洩を助長したいわけではなく、そのリスクを理解したうえで安全なコードを書く方法をお伝えしたい記事になります。釣りタイトルの様になってますがご了承下さい。
クロスリクエスト状態汚染とは
クロスリクエスト状態汚染を英語に直すと「cross-request state pollution」となり、薄眼で見たらCSRF(cross site request forgery)に見えなくもないですが全くの別物です。
まず、Vueの公式サイトに記載されている内容をそのまま引用します。
SSR のコンテキストでは、アプリケーションモジュールは通常、サーバーが起動したときに一度だけ初期化されます。同じモジュール・インスタンスが複数のサーバー・リクエストにまたがって再利用されるので、シングルトンの状態オブジェクトも同じように再利用されます。あるユーザーに固有のデータを含む共有シングルトンの状態を変更した場合、誤って情報が他のユーザーからのリクエストに漏れてしまうことがあります。これを cross-request state pollution（クロスリクエスト状態汚染） と呼びます。
上記の記載内容だけみてもイメージがつかないかもしれませんので、一つずつ読み解いていきましょう。
シングルトンパターン
SSR のコンテキストでは、アプリケーションモジュールは通常、サーバーが起動したときに一度だけ初期化されます。同じモジュール・インスタンスが複数のサーバー・リクエストにまたがって再利用されるので、シングルトンの状態オブジェクトも同じように再利用されます
まず、上記のことをちゃんと理解するためにはシングルトンについて理解していく必要があります。
一言でいうと、シングルトン(singleton) とは「一度だけインスタンス化でき、どこからでもアクセスできるクラス・オブジェクト」のことです。この単一のインスタンスはアプリケーション全体で共有することができ、複数のサーバー・リクエストで再利用できることからグローバルな状態管理に適していると言えます。
では基本的なTypeScriptのプログラムでシングルトンの例を見ていきましょう。
※以下フロントエンドのデザインパターンの引用を多く含みます。もっと詳しく知りたい方は第3章シングルトンパターンを参照ください。
let counter = 0;
class Counter {
getInstance() {
return this;
}
getCount() {
return counter;
}
increment() {
return ++counter;
}
decrement() {
return --counter;
}
}
const counter1 = new Counter();
const counter2 = new Counter();
このCounterクラスはシングルトンではありません。シングルトンは一度しかインスタンス化できないはずですが、newメソッドを2回呼び出すことでcounter1とcounter2に異なるインスタンスを入れることができています。
このように複数回呼び出すことでインスタンスが異なったり初期化されるものはシングルトンにはならないということなので、関数についても同様のことが言えます。
let counter = 0;
function increment() {
console.log("Hello~~");
counter++
return counter;
}
increment();
increment();
increment関数についても複数回呼び出すことができますのでシングルトンではありません。
しかし、NuxtにおいてのSSRではcounter変数が（共有）シングルトンとなり、誤って情報がほかのユーザーに漏れてしまうパターンがあります。
その実例を次で見ていきましょう。
情報漏洩させてみよう
ここからは、Nuxt3のSSRで情報漏洩リスクのあるコードとはどういったものなのか、サンプルコードを見ながら解説していきます。
サンプルコードは以下のリポジトリにも格納しているのでこちらを見ながら、もしくはクローンして動かしながら確認することを推奨します。
また、Nuxt3及びTypeScriptの詳細については本記事では解説いたしませんのでご了承ください。
ではまず、composables配下にmoreru.tsというファイルを作成し以下のコードを書いたとしましょう。
const moreru = ref(0)
export const useMoreru = () => {
const morenaide = ref(0)
const incrementMoreru = () => {
morenaide.value++
moreru.value++
}
return { moreru, morenaide, incrementMoreru }
}
このuseMoreruという関数は、グローバルに宣言されたmoreruというリアクティブ変数とuseMoreru関数内に宣言されたmorenaideをインクリメントするincrementMoreruメソッドを持っています。
では、このuseMoreru関数をページから呼び出してみましょう。
<script setup lang='ts'>
const { moreru, morenaide, incrementMoreru } = useMoreru()
incrementMoreru()
console.log("moreru", moreru.value)
console.log("morenaide", morenaide.value)
</script>
<template>
<div>
<h1>Hello World</h1>
<p>moreru: {{ moreru }}</p>
<p>morenaide: {{ morenaide }}</p>
<NuxtLink href="/about">About</NuxtLink>
</div>
</template>
indexページでは、useMoreruを呼び出したうえでincrementMoreruを実行し、インクリメントした値をそれぞれロギング及びレンダリングをしています。
ここまでできたらnpm run devして開発サーバーを立ち上げましょう。
この時、クロスリクエスト状態汚染が分かりやすくするために、複数タブでlocalhost画面を開いておいてください。
サーバーが起動しきったら、分割した画面の内左側の画面で開発者ツールを表示し、コンソールからロギングした結果を確認してみて下さい。
以下の様になっているのではないでしょうか？
続いてSSR側でのロギングの結果も確認しておきましょう。
この段階ではそれぞれ一度しか呼び出されていないのでSSRとブラウザ側での値には差はありません。
では、右側に分割した画面の出力結果を確認してみましょう。
画面の表示は先ほどと変わりませんね。SSR側でのロギングの結果はどうでしょう。
おや...？moreruが2になっていますね。
つまり、左側の画面で0⇒1にインクリメントした値に対して、さらにインクリメントしている（1⇒2）ということになります。
そう、つまりこれこそがクロスリクエスト情報汚染が起きているということなのです。
NuxtSecurityのNuxt SSR で状態を慎重に扱うでも言及されていますが、composable内のグロバール変数は共有シングルトン状態であるため、この値をリクエストごとに書き換えるようなコードを書いてしまうと、あるユーザーによって上書きされた値がまた別のユーザーに漏れてしまうといったことが起きてしまいます。
一方でuseMoreru関数内に閉じ込めているmorenaide変数は関数の呼び出し毎に初期化されるためシングルトンではありません。
実際サンプルでも、SSR側でもブラウザ側でも値が毎回1になっていますよね。
今回の例ではただの数値が漏れているだけなので危険性はないかもしれませんが、この値がユーザー固有の情報（指名、メールアドレス、住所など）だと考えるとゾッとしますよね...
事例
実際、クロスリクエスト状態汚染によって情報漏洩が起きてしまっている事例は存在しています。蒸し返すようなことになるとよくないので具体的な言及は避けますが、ググればいくつか事例は出てきますので、気になった方は調べてみてください。（実際謝罪文みると気が引き締まる気はしますw）
まとめ
ここまで読んでくださりありがとうございました。
クロスリクエスト状態汚染についてサンプルコードを用いて説明してきましたが、サンプルコードの書き方だけ気を付けていれば全く問題ないのかというとそうではありません。あくまで一例だと思ってくださると幸いです。
参考リンク