リポジトリ内のプロトタイプ汚染を防ぐ

Aikido Autofix Pull Requestから直接このページにたどり着き、PRを完成させる方法だけを知りたい場合は、「実装方法」まで読み飛ばしてください。

JavaScriptエコシステムには問題があり、それはプロトタイプ汚染と呼ばれている。JavaScript/npmを使って構築しているSaaS企業では、依存関係から検出される既知の脆弱性（CVE）のうち、通常最大20～30％がプロトタイプ汚染によるものだ。これらは通常、悪用するのは簡単ではないが、ひどい場合にはリモートコード実行の欠陥につながる可能性がある。つまり、完全に無視することは難しいのだ。

試作品の汚染を防ぐ2つの方法

Node.jsには、-frozen-intrinsicsと呼ばれるフラグの下でデフォルトでプロトタイプをフリーズする実験的なサポートがある。このフラグを有効にすると、プロトタイプ汚染攻撃はすべて無効になる。しかし、これは実験的なものであり、フロントエンドのコードベースでは動作しないため、まだ推奨できない。そのため、フロントエンドとバックエンドで同じ保護を構築することができません。

代替案はnopp（No Prototype Pollution）で、プロトタイプ（と他のいくつかのエントリーポイント）をフリーズさせる14行のライブラリである。

実施方法

1.ライブラリのインポート

noppをインストールしたら、あとはアプリを起動するスクリプトにアクセスするだけだ。そこで、他のライブラリーを全てrequireした後に、ライブラリーをrequireするだけだ。以下のコミット例：

2.プロトタイプ操作に依存するライブラリのアプリ全体の安全性チェック

他のライブラリを含めた後にプロトタイプをフリーズさせる理由は、他のライブラリの中には、動作するためにプロトタイプを変更することに依存しているものがあるかもしれないからです！他のライブラリを追加した後でプロトタイプをフリーズさせたとしても、アプリが再び動作するまでにリファクタリングが必要になる可能性があります！

例えば、Amazonのaws-sdk for Node.jsは、"new AWS.S3(...) "のようなオブジェクトを作成する際にプロトタイプを変更する。このような場合、Node.jsのプロセスが起動したときにオブジェクトが作成されるようにし、後のフェーズではオブジェクトが作成されないように、以下のようにリファクタリングする必要があるかもしれません。

この変更後もアプリが動作することを確認するのは、テスト・カバレッジが低い大規模リポジトリにとっては、より大きな時間投資となるかもしれない。小規模なリポジトリでは、プロトタイプの汚染に再び対処する必要がなくなるため、それだけの価値はあるだろう。大規模なリポジトリでは、この作業はより複雑になるかもしれないが、エンジニアリングへの投資は長期的にはプラスのROIをもたらすだろう。