はじめに
― ツールだけでは見つけられない“JS特有の闇”と、自動化ツールの最新動向 ―
Prototype Pollution は JavaScript の構造そのものを悪用する脆弱性であり、
SQL Injection や XSS とは違って「特定パターンにマッチすれば見つかる」ような単純な問題ではありません。
実際、多くのセキュリティ研究者が口を揃えて言います：
“Prototype Pollution の検出は、JavaScript が prototype-based 言語である以上、本質的に難しい。”
この記事では、その理由と、自動化に取り組む現代の OSS ツールたちの実力をまとめていきます。
1. なぜ Prototype Pollution の自動検出は難しいのか？
Prototype Pollution が厄介な理由は、JS の基本仕様に深く根ざしています。
① オブジェクトがプロトタイプを共有する仕組みが複雑
JavaScript のオブジェクトは、prototype を介して暗黙的に機能を共有しています。
つまり、あるオブジェクトに対する操作が：
- “それ自身への変更なのか”
- “prototype への変更なのか”
- “下層/上層オブジェクトへ影響するのか”
がコードを読んだだけでは判断しづらい。
静的解析ツールにとっては、これが地獄の鬼門。
② アプリケーションごとにコード構造が全く異なる
Prototype Pollution を引き起こす一般的なパターンはあるものの…
- マージ処理
- ディープコピー処理
- 設定オブジェクトの更新
- 動的なプロパティ代入
これらがどのように実装されているかは アプリごとに完全にバラバラ。
そのため、万能スキャナーを作るのはほぼ不可能。
③ 「入力 → プロパティキー」への流れを追う必要がある
脆弱性が発生する条件は：
ユーザーがコントロール可能なキーが、
何らかの merge / assign / clone に渡されること。
つまりツールは：
- データフロー解析
- オブジェクト構造追跡
- プロトタイプチェーンの把握
- 関数の再帰構造解析
これらを同時に行う必要があり、高度な推論力が求められます。
2. 現場では「人間が読む」ことが今も必須
Prototype Pollution の検出は、XSS や SQLi と違って：
- 特定の payload があれば見つかる
- パターンマッチで検出できる
…というタイプの脆弱性ではありません。
実際、優秀なツールを導入しても：
- 誤検知（false positive）は多い
- 未検知（false negative）も当然出る
- コード全体の文脈理解はツールには不可能
最終的には セキュリティエンジニア／開発者のコード理解 が必須となります。
Prototype Pollution を自動検出できるツールは“補助輪”であり、
決して“自動操縦パイロット”ではない。
3. 自動化を助ける代表的なツールたち
それでもセキュリティコミュニティは諦めていません。
いくつかの OSS プロジェクトが、Prototype Pollution の検出を支援するツールを提供しています。
3.1. NodeJsScan
GitHub: https://github.com/ajinabraham/nodejsscan
Node.js アプリに特化した静的解析ツール。
Prototype Pollution を含む多数の脆弱性チェックを備えています。
- Node.js アプリのセキュリティ検査に最適
- CI/CD に統合しやすい
- merge / assign / object 操作まわりのパターンに反応
3.2. ProtoScan
GitHub: https://github.com/KathanP19/protoscan
JavaScript コードのプロトタイプ汚染を専門にスキャンするツール。
特徴：
- 可疑なキー操作を検知
- merge 系処理の流れを解析
- 開発中の JavaScript アプリに組み込むことで早期発見に役立つ
3.3. PPFuzz
GitHub: https://github.com/dwisiswant0/ppfuzz
Prototype Pollution を “動的” に見つけるための fuzzing ツール。
仕組みはこう：
- 汚染しやすいキー（
__proto__,constructor,prototypeなど）を自動送信 - アプリの挙動変化を監視
- 汚染成功ポイントを自動探索
Web アプリのブラックボックステストにも利用可能。
3.4. Client-side Prototype Pollution（BlackFan）
GitHub: https://github.com/BlackFan/client-side-prototype-pollution
クライアント側（ブラウザ）での Prototype Pollution を研究したプロジェクト。
- XSS と PP の組み合わせ攻撃例が豊富
- 実際のブラウザ動作がどう変わるかを確認できる
- フロントエンド開発者にも必見の教材
4. Pentester / Developer が着目すべきポイント
Prototype Pollution を手動で調査する際、最低限チェックすべきポイントはこちら：
① ユーザー入力が「プロパティ名」になる場所
例：
obj[userInput] = value;
merge(config, req.body);
deepClone(req.query);
こうした箇所は即チェック対象。
② マージ・クローン関数にフィルタがあるか
安全な例：
if (key === "__proto__" || key === "constructor") continue;
危険な例：
for (let key in from) {
to[key] = from[key]; // 無防備
}
③ 任意オブジェクトの JSON パース
prototype 汚染の温床：
JSON.parse(userInput)
特に「名前」「タイトル」「設定値」など
本来 JSON であるべきでない入力を JSON.parse している場合は危険。
まとめ：自動化ツールは“補助”、最終判断は“人”
Prototype Pollution は JS の柔軟性ゆえに発生する脆弱性であり、
完全自動化は極めて難しい領域です。
しかし、紹介した OSS ツールを組み合わせることで：
- コードレビューの効率化
- 潜在的ホットスポットの可視化
- CI/CD による継続監視
といった効果は十分に得られます。
最も重要なのは：
「キーがユーザーにコントロールされるか？」
「prototype に到達しうる経路があるか？」
この 2 点を人間が理解して判断すること。
Prototype Pollution の見極めは “アート” の領域でもあります。