JSONの重複キーに潜む解釈の脆弱性

今回はウェブの世界の共通語とも言える JSON について、ちょっと深く掘り下げていきたいなと思ってます。 JSON ですか。へえ、いいテーマですね。皆さんも API とか、設定ファイルとかでお馴染みだと思うんですけど、そのシンプルさの裏にある奥深さというか。 特にセキュリティの観点から見ていきたいです。はい。シンプルだからこそ、見過ごされがちなポイントってありますよね。 そうなんです。まず JSON のデータを理解するコツとして、私がすごく気に入っているのがあります。 ほう。問いと答えのリズムで捉えるというやり方なんです。問いと答え。 ええ。例えば、"age" と "25" というデータありますよね。 はい、ありますね。これを キー "age"、値 "25" と機械的に読むのではなく、 「年齢は？」と聞いたら「25歳です」みたいな。なるほど。会話のキャッチボールですね。 それはすごく分かりやすい。この感覚だと複雑なデータもすっと頭に入ってくる気がします。 まさにその通りだと思います。だからこそ、プログラマーじゃなくても人間が読んで直感的に理解できる。 それが、かつて主流だった XML とか、他の形式に対する JSON の大きな利点になったわけですね。 うーん。この問いと答えのペアを、括弧で囲めば オブジェクト、つまり箱になって。 括弧で囲めば今度は リスト になる。ルールが本当に最小限なんですよ。 そのシンプルな形式が今や本当に色々なところで活躍していますよね。ええ。 代表的なのはやはり3つの場面ですかね。一つは、ウェブサイトの裏側と表側が情報やり取りする API でのデータ交換。 これはもう標準中の標準です。はい。二つ目がアプリケーションの設定ファイル。 三つ目が、これが意外と強力なのですが、SEO です。あ、JSON-LD のことですね。 そうです、そうです。あれはもはや単なるデータ交換というより、Google との対話言語みたいになっている感じがします。 まさしく。ウェブページに価格とかレビューのような構造化された情報を埋め込むことで、検索エンジンが「このページはこういう内容なんだな」と正確に理解してくれるわけです。 結果として検索結果もリッチになる。そういうことですね。なるほど。 API から SEO まで本当に万能なんですね。でもここからが本題で、そのシンプルさが逆に問題を引き起こすケースがあるという。 資料を拝見してここが一番気になりました。はい。JSON相互運用性の脆弱性と呼ばれる問題ですね。 実は JSON の公式ルール RFC と言うのですが、これにはどうとでも解釈できてしまう、ちょっと曖昧な部分がいくつか残っているんです。 曖昧な部分ですか。例えば、オブジェクト の中で キー が重複していた場合、どちらを優先しますかというルール。 これが実は明確に決まってないんですよ。え、そうなんですか。では、同じデータのはずなのに受け取るシステムによって中身が変わってしまう可能性があるということですか。 その通りです。パーサー、つまり解釈するプログラムの実装次第で変わってしまう。 うわあ。そこに攻撃の隙が生まれるわけですね。なるほど。具体的なシナリオを挙げると分かりやすいと思います。 ある ECサイト で悪意のあるユーザーが "count": 1、"count": 100 という注文リクエストを送ったとします。 キーが重複していますね、"count" が。はい。そしてこの ECサイト の裏側が、支払いシステムAと受注システムBという2つの別々のシステムで動いていたとします。 ふむふむ。もし支払いシステムAが最初に現れた キー を優先するという仕様だったら、決済されるのは 1個分だけですね。そうです。1個分の代金です。ところが受注システムBの方が最後に現れた キー を優先するという仕様だったらどうでしょう。 そっちは100個の注文として受け付けちゃうわけですか。そうなんです。うわあ、それはまずい。 1個分の支払いで100個の商品が手に入ってしまう。これが 解釈の違いによって生まれるセキュリティホール です。 データは全く同じなのに、システムごとの癖によって意味が変わってしまうんです。 なるほどなあ。これは怖いですね。まとめると JSON は、問いと答えのリズムで直感的に理解できるすごく強力なツール。 だけどそのシンプルさと仕様の曖昧さがシステム間の解釈のずれを生んでしまう。 それが予期せぬ脆弱性につながることがあると。ええ、そういうことになります。 データは正しく書かれているだけでは不十分で、相手にどう解釈されるかまで想像する必要があるという教訓でもありますね。 いや、深いですね。あ、そうだ。最後に一つ、ちょっと面白い問いかけをしてもいいですか。 ぜひお願いします。JSON の仕様では オブジェクト 内の キー の順序は保持される保証がないんですよ。 あ、そうでしたね。順番は保証されない。はい。もし処理の順序がものすごく重要なデータ、例えば ステップ1 認証、ステップ2 決済のようなものを扱う場合を考えてみてください。 ええ。これが受け取った側で順序が入れ替わってしまったら、一体何が起こると思いますか？ 認証する前に決済が走ったら大変なことになりますよね。 データの見た目と、その本質的な意味の違いについて少し考えてみるのも面白いかもしれません。