JSON重複キーが招く解釈の揺れと脆弱性

さて、あなたがリアクトで素晴らしいフロントエンドを作って、ギャースで便利な自動化を組んだとします。 でもこの2つって、どうやって会話させればいいんでしょうか？ 今回はですね、あなたが共有してくださった資料をもとに、この異なるシステムをつなぐユニバーサル翻訳機、 JSONについて、その情報の梱包術と、えっと、意外な落とし穴を深掘りしていきます。 はい。インターネット越しにデータを送るにはですね、プログラムが扱う複雑なデータ、 つまりオブジェクトを、一旦ただのテキスト、文字列に変換する必要があるんですよ。 このための共通ルールがJSONなんです。なるほど。 資料にあった「データのフリーズドライ」っていう比喩、あれ秀逸ですよね。送る側で情報をテキスト形式にギュッと固めて、受け取る側で元に戻す。 まずはこの梱包と回答のプロセスから見ていきましょうか。フリーズドライ、面白いですね。 最初のステップは、じゃあ、Reactが持っているJavaScriptのオブジェクトを、いわば 国際郵便で送れる手紙の形にするということですね。資料にあったJSON.stringifyというのがその梱包作業に当たる。 と、まさにその通りです。stringify、まあ、つまり文字列化ですね。ただ、ここで一つ重要なのが、 JavaScriptのオブジェクトとJSON文字列って、見た目はすごく似てるんですけど、全くの別物だということです。ほう。 JSONには、より厳格なルールがあるんです。例えば、キーは必ずダブルクォートで囲む必要があります。 あ、なるほど。JavaScriptだとシングルクォート、かっこでも書けちゃいますけど、この共通ルールの世界では通用しない、と。 見た目がそっくりなだけに、これは、えっと、つまづきやすいポイントかもしれないですね。 ええ。さらに言うと、扱える値も、文字列、数値、真偽値、Null、配列、オブジェクトだけなんです。 JavaScriptのオブジェクトみたいに、関数とかデート型は直接含められないんですよ。 この厳格さこそが、どんな環境でも同じようにデータを扱えるようにするための、まあ鍵なんです。 なるほど。そして、JS側から送られてきたその手紙を、今度はReact側で開封して中身を理解する必要があると。 それがJSON.parseを使った回答のプロセスっていうわけですね。その通りです。 このstringifyとparseという一対の儀式で、システム間の安全なデータ交換が成り立っているわけです。 そのルールが厳格なのは、まさにどのシステムでも同じように解釈できるようにするためですよね。 でも、その同じ解釈という大前提が、もし、もしも崩れるとしたらどうなるのか？ 資料によると、そこにかなり大きな落とし穴があるようですが。 それがJSONパーサーの「解釈の揺れ」という問題です。同じJSONテキストでも、 読み取る言語とかライブラリが違うと、解釈結果が変わることがあるんです。え、そんなことが。 はい。その最も分かりやすい例が、重複したキーの問題ですね。キーが重複する、ですか。 ええ。例えば、QTY -1、QTY 1というJSONがあったとします。 この場合、QTYの値って、-1になると思いますか？それとも1になると思いますか？ うーん、普通に考えたらエラーになりそうですけど。 実は、公式仕様であるRFC 8259では、どちらの挙動も許容されているんです。えっと、仕様で決まってないんですか？ それは驚きです。そうなんですよ。最初の値を採用するパーサーもあれば、最後の値を採用するパーサーもある。 ということは、資料にあったECサイトの例は、まさにこの曖昧さが引き起こした脆弱性の話だったんですね。 まず、Python製のカートサービスがこの注文を検証します。 このサービスのパーサーは最後のキーを優先するタイプなので、QTYは1と解釈して注文を承認します。 なるほど。カートサービスは注文を有効だと判断した。でも、決済サービスに渡されたのは、 あくまでもあの曖昧なJSON文字列のままなんですよね。その通りです。 次に、Go言語で書かれた決済サービスがそのJSON文字列を受け取って処理する。しかし、 こちらのパーサーは最初のキーを優先するものだったんです。ということは、 決済サービスはQTYを-1と解釈してしまう。顧客は商品を受け取るのに、 料金は請求されないどころか、むしろ返金されてしまう。これは恐ろしいビジネスロジックの脆弱性ですね。 今回の話の核心はまさにそこなんです。JSONはstringifyとparseで安全にデータをやり取りできる、すごく強力な仕組みです。 ですが、そのシンプルさの裏で、重複キーのような曖昧な仕様がセキュリティリスクに直結し得るというわけです。 なるほど。そこで、あなたに最後の問いかけです。資料によると、一部の開発者は、 この重複キーの仕様を逆手にとって、テスト、これは説明用のコメント、テスト、実際の値、のように意図的に利用することがあるそうです。 パーサーごとの解釈の違いを知った今、あなたにはこれが賢いテクニックに見えますか？それとも将来の時限爆弾に見えるでしょうか？