プロトタイプ汚染(Prototype Pollution)の仕組みと対策。継承を断ちObject.prototypeを守る

プロトタイプ汚染(Prototype Pollution)は、JavaScriptのオブジェクトが共有する親であるObject.prototypeを、外部からの入力で書き換えられてしまう欠陥です。JavaScriptのほとんどのオブジェクトはObject.prototypeを継承しているため、この共有された親に一度プロパティが差し込まれると、その後に作られるものを含めてほぼ全てのオブジェクトがその影響を受けます。単体では実害が見えにくい一方で、ほかの欠陥と組み合わさると認可の回避やサービス停止、条件次第では任意コード実行にまで発展しうる、影響範囲の広い問題です。

この記事は、WebフロントエンドとNode.jsのバックエンドを実装する開発者に向けて、なぜ信頼できない入力の扱い方ひとつでObject.prototypeが汚染されるのかを機構レベルで整理し、継承を断つ設計と危険なキーの拒否で塞ぐ方法をまとめます。攻撃の再現手順や動くペイロードは扱わず、仕組みと防御実装に力点を置きます。

プロトタイプ汚染が成立する機構#

JavaScriptでは、オブジェクトリテラルや配列などのほとんどのオブジェクトが、Object.prototypeという共通の親を通じてプロパティを継承します。あるオブジェクトに存在しないプロパティを参照すると、実行環境は継承の連鎖(プロトタイプチェーン)をたどって親をさかのぼり、Object.prototypeまで探しにいきます。この仕組みのおかげで、toStringやhasOwnPropertyのような共通のメソッドをどのオブジェクトからも呼べます。裏を返せば、Object.prototypeに何かを書き加えると、その追加分は連鎖をたどる全てのオブジェクトから見えるようになります。

問題は、その共有された親へたどり着く経路が、オブジェクトのプロパティ名として表に出ている点にあります。__proto__はオブジェクトの親(内部の[[Prototype]])を読み書きするアクセサで、多くの場合Object.prototypeを指します。同様にconstructorをたどると生成元の関数に届き、そこからprototypeをたどると再び共有された親に到達します。つまり、外部から与えられた名前でオブジェクトのプロパティを入れ子にたどりながら書き込む処理は、__proto__やconstructorを渡されると、個々のオブジェクトではなく共有された親へ書き込みを届かせてしまいます。一方で、obj["__proto__"] = vのような一段だけの代入は、そのオブジェクト自身の親(内部の[[Prototype]])を差し替えるだけで、共有されたObject.prototypeは汚染しません。たとえばtarget[k1][k2] = vでk1が__proto__のときは、target["__proto__"]がObject.prototypeを指すため、実質的にObject.prototype[k2] = vが起こります。constructor経由でも、constructorからprototypeへと段階的にプロパティをたどって共有された親に到達し、同じことが起こります。標的になりやすいのは全オブジェクトへ影響するObject.prototypeですが、原理としては到達できる任意のプロトタイプオブジェクトが対象になります。

この経路が開くのは、典型的には信頼できない入力を安全でない再帰マージやディープクローン、あるいはドット区切りのパスによるネストしたプロパティ設定で処理するときです。受け取ったキーの名前を検証せずにオブジェクトへ差し込む実装は、__proto__やconstructor、prototypeといった特別なキーもそのまま受け入れ、共有された親に新しいプロパティを生やしたり、既存のプロパティを別の値へ置き換えたりできてしまいます。JSONのパース自体は__proto__を通常のキーとして扱うため、パースした結果をあとからマージする段で汚染が起こります。

MITREのCWE-1321は、上流のコンポーネントから受け取った入力がオブジェクトの属性を初期化または更新するにもかかわらず、オブジェクトプロトタイプの属性への変更を適切に制御しない欠陥をプロトタイプ汚染と定義しています。__proto__やconstructor、prototypeといったプロトタイプへアクセスできる特別な属性を通じて悪用され、ユーザー入力に基づいて属性を設定する処理や、オブジェクトを再帰的にマージまたはクローンする処理でよく生じると説明しています。影響としてはアプリケーションデータの読み書きや、型の異なる値での上書きによる可用性への影響を挙げ、緩和策としてObject.freeze(Object.prototype)、危険なキーの拒否、Object.create(null)やMapの利用、スキーマ検証を示しています。

汚染が実害につながる筋道#

Object.prototypeに差し込まれたプロパティそのものが、ただちに攻撃になるわけではありません。実害は、汚染で生えたプロパティが、アプリケーションのどこかで意味のある値として使われたときに現れます。PortSwiggerのWeb Security Academyは、プロトタイプ汚染の悪用が成立するには三つの要素が要ると整理しています。汚染の入口となる攻撃者が制御できる入力(ソース)、汚染されたプロパティが危険な形で使われる箇所(シンク)、そしてソースからシンクへ値を運ぶ橋渡しのプロパティ(ガジェット)です。

この三点がそろうと、汚染は具体的な不具合に化けます。存在しないはずのプロパティが常に存在するように見えることで、条件分岐が意図せず真になり、権限チェックや機能フラグの判定が狂ってロジックや認可の回避につながります。あるいは、内部で使われる設定値やオプションが汚染で上書きされ、型の食い違いから例外が多発してサービスが止まる、といった可用性への影響も起こります。共有された親に残った汚染は、それを触った全てのオブジェクトへ効くため、原因の切り分けが難しくなりがちです。

外部から来た値をどう検証し、どこで信頼するかという設計の土台は、次の記事で整理しています。

あわせて読みたい

入力バリデーションと出力エスケープの原則。入口で検証し、出口で文脈別にエスケープする

クライアント側とサーバ側の違い#

プロトタイプ汚染は、動く場所によって行き着く先が変わります。ブラウザで動くクライアント側では、汚染されたプロパティがDOMを操作するAPIやスクリプトの挿入経路に流れ込むと、DOMベースのXSSに至ることがあります。汚染で生えたプロパティが、本来は指定されていないはずのHTMLの断片やスクリプトのソースとして使われ、ページ内で意図しないスクリプトが動く筋道です。DOMベースのXSSそのものの仕組みは、次の記事で扱っています。

あわせて読みたい

XSS（クロスサイトスクリプティング）の仕組みと対策。反射型・格納型・DOM型を原理から整理

一方、Node.jsで動くサーバ側のプロトタイプ汚染は、表からは見えにくいものの、条件によってはより重い結果を招きます。PortSwiggerは、サーバ側では汚染されたプロパティが子プロセスを起動する処理などのシンクに届くと、任意コード実行につながりうると説明しています。汚染がリクエストの処理をまたいでプロセス全体に残るため、ある利用者の入力が別の処理の挙動を変えるという、状態の共有ならではの厄介さも伴います。

PortSwiggerのWeb Security Academyは、プロトタイプ汚染を、攻撃者がグローバルなオブジェクトプロトタイプへ任意のプロパティを追加でき、それがユーザー定義のオブジェクトに継承されうるJavaScriptの脆弱性と定義しています。悪用にはソース、シンク、ガジェットの三要素が必要で、クライアント側では主にDOMベースのXSSに、サーバ側ではNode.jsの脆弱なメソッドを介して任意コード実行やサービス拒否に至りうると整理しています。サーバ側は検出が難しい一方でリスクは大きいとしています。

継承を断つ設計と危険キーの拒否#

対策の根本は、信頼できないキーがプロトタイプへ到達して書き込むのを許さない、という一点にあります。具体的な手立ては二つです。ひとつは、辞書用途の入れ物に、キー名がプロトタイプチェーン上のプロパティにならない構造を使い、汚染の届く先をなくすことです。もうひとつは、共有された親へたどり着くキーを入口で拒否し、共有された親そのものを書き換え不能にすることです。OWASPのPrototype Pollution Prevention Cheat Sheetは、この方向に沿った具体策を挙げています。

継承を断つ考え方が最も素直に効くのはObject.create(null)です。プロトタイプがnullの素のオブジェクトなのでObject.prototypeを継承せず、__proto__というキーも共有された親への近道ではなく、ただの文字列のプロパティになります。Mapはしくみが異なります。Mapインスタンス自体はMap.prototypeを介してObject.prototypeを継承しますが、set()やget()で渡したキーはMap内部のエントリとして保持され、オブジェクトのプロパティ名にはなりません。そのため__proto__のようなキー名を渡してもプロトタイプチェーン上のプロパティにはならず、汚染の経路になりません。ユーザー入力をキーとして格納する入れ物には、オブジェクトリテラルではなくObject.create(null)やMapを使うのが確実です。

危険なキーの拒否は、汚染への経路を入口で断ちます。再帰マージやプロパティ設定を自作するなら、キー名が__proto__、constructor、prototypeのいずれかに一致する場合は処理をスキップまたは拒否し、できれば想定するキーの許可リストで検証します。既存のライブラリに頼る場合は、プロトタイプ汚染への対策が入った保守されているバージョンを使い、脆弱性情報を追える状態にしておきます。

利用しているライブラリに既知のプロトタイプ汚染が残っていないかを継続的に把握する仕組みは、次の記事で扱っています。

あわせて読みたい

依存ライブラリ管理とSCA。SBOMで攻撃面を把握する

Object.freeze(Object.prototype)は、共有された親を凍結して新しいプロパティの追加や既存プロパティの変更を拒むため、たとえ危険なキーが差し込まれても書き換えが成立しなくなります。効かせるには、信頼できない入力を処理し始めるより前、できるだけ早い起動段階で適用します。守れるのはObject.prototypeだけで、ほかのプロトタイプや代入先自身の親([[Prototype]])の差し替えは防げないため、危険なキーの拒否を置き換えるものではなく、多層防御の一枚として重ねます。組み込みのプロトタイプを書き換えて動くライブラリがあると壊れるため、導入前に依存関係の挙動を確認します。Node.jsでは、起動時に--disable-proto=deleteを渡すとObject.prototype.__proto__というアクセサ自体が取り除かれ、throwを指定すればアクセス時にERR_PROTO_ACCESSという例外を投げます。これは__proto__という経路を実行環境の側で塞ぐ、多層防御の一枚として働きます。

OWASPのPrototype Pollution Prevention Cheat Sheetは、オブジェクトリテラルの代わりにnew Set()やnew Map()を使うことを勧めています(値の集合にはSet、キーと値の対応にはMap)。オブジェクトが必要な場合はObject.create(null)でObject.prototypeを継承しないように作るとしています。組み込みのプロトタイプの変更を防ぐためにObject.freeze()やObject.seal()を使えるとしつつ、プロトタイプを書き換えるライブラリがあるとアプリケーションが壊れうると注意しています。さらにNode.jsでは--disable-proto=deleteで__proto__プロパティを取り除けると紹介しています。

信頼できないデータを構造ごと復元する処理は、プロトタイプ汚染と同じく入力の扱いに注意が要ります。安全でないデシリアライゼーションの考え方は、次の記事とあわせて読むと土台が固まります。

あわせて読みたい

安全でないデシリアライゼーションの対策。信頼できないデータの復元が任意コード実行につながる仕組み

まとめ#

プロトタイプ汚染(CWE-1321)は、JavaScriptのオブジェクトが共有する親であるObject.prototypeを、外部からの入力で書き換えられてしまう欠陥です。信頼できない入力を安全でない再帰マージやプロパティ設定で処理し、__proto__やconstructor、prototypeというキーを許すと、共有された親が汚染され、以降ほぼ全てのオブジェクトへ影響が波及します。単体では悪用しにくくても、ほかの欠陥と連鎖すると、クライアント側ではDOMベースのXSS、サーバ側では条件次第で任意コード実行やサービス停止にまで発展しうる点が、この問題の広がりです。

対策の軸は、辞書用途の入れ物でキー名をプロトタイプチェーン上のプロパティにしないことと、共有された親へたどり着くキーを入口で拒否し、共有された親そのものを書き換え不能にすることです。Object.create(null)やMapの利用、危険なキーの拒否と構造の検証、Object.freeze(Object.prototype)やNode.jsの--disable-proto、保守されたライブラリへの依存を重ねれば、単一の対策に頼らずに汚染の経路を塞げます。

Webアプリの代表的な弱点を全体像として押さえたい場合は、次の記事が入口になります。

あわせて読みたい

OWASP Top 10とは。開発者が押さえるべきWebの代表的リスクと対策を一気に理解する