ウェブアプリケーションセキュリティ 第2版

第35章. サードパーティの依存関係を保護する

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

第6章では、ファーストパーティーのウェブアプリケーションにおけるサードパーティーの依存関係を特定する方法を調査した。第 17 章では、サードパーティの依存関係がファーストパーティのウェブ・アプリケーションに統合され ている様々な方法を分析した。統合に基づき、潜在的な攻撃ベクトルを特定し、そのような統合を悪用する方法について議論することができた。

パート IIIは、 ハッカーを阻止する防御テクニックがすべてなので、この章は、サードパーティの依存関係を統合するときに発生する可能性のある脆弱性から、アプリケーションを保護することがすべてである。

ディペンデンシー・ツリーを評価する

サードパーティの依存関係を考えるときに最も重要なことのひとつは、サードパーティの多くはそれ自身の依存関係を持っているということだ。このような依存関係のことをサードパーティ依存関係と呼ぶこともある。

サードパーティの依存関係を1つだけ手動で評価することは可能である。サードパーティの依存関係をコードレベルで手動評価することは、多くの場合において理想的である。

残念ながら、手作業によるコードレビューは、特にうまくスケールしない。多くの場合、第4者の依存関係に依存するサードパーティ依存関係を包括的にレビューすることは不可能だろう。特に、第4者の依存関係に独自の依存関係が含まれている場合などはなおさらだ。

サードパーティの依存関係、その依存関係、依存関係の依存関係などが、依存関係ツリーと呼ばれるものを構成する（図35-1を参照）。npm を使ったプロジェクトでnpm ls コマンドを使うと、依存ツリー全体をリストアップして評価することができる。このコマンドは、アプリケーションに実際にどれだけの依存関係があるかを確認するのに強力である。

図35-1. npmの依存関係ツリー

依存関係ツリーは、ソフトウェアエンジニアリングにおいて重要である。なぜなら、依存関係ツリーは、包括的なアプリケーションのコードを評価することを可能にし、ファイルサイズとメモリサイズを劇的に削減することができるからである。

依存関係ツリーをモデリングする

次のような依存関係ツリーを持つアプリケーションを考えてみよう：

主要アプリケーション → JQuery

プライマリアプリケーション → SPAフレームワーク → JQuery

主要アプリケーション → UIコンポーネント・ライブラリ → JQuery

依存関係ツリーをモデル化できれば、アプリケーションは依存関係の連鎖の3つの部分がJQueryに依存していることを特定できる。その結果、JQueryを3回インポートする（ファイルとメモリの冗長性が生じる）のではなく、1回インポートして多くの場所で使用することができる。

依存関係ツリーのモデリングは、セキュリティ工学においても重要である。なぜなら、適切な依存関係ツリーのモデリングがなければ、ファーストパーティ・アプリケーションの各依存関係を評価することは非常に難しいからである。

理想的な世界では、（前述の例のように）JQueryに依存して関数が動作するアプリケーションの各コンポーネントは、同じバージョンのJQueryに依存している。しかし現実の世界では、そうなることはほとんどない。ファーストパーティのアプリケーションは依存関係のバージョンを標準化することができるが、ファーストパーティのアプリケーションが依存関係の連鎖の残りの部分を標準化する可能性は低い。なぜなら、依存関係の連鎖の各項目は、バージョンごとに異なる機能や実装の詳細に依存している可能性があるからである。依存関係をいつ、どのようにアップグレードするかの哲学も、組織によって異なる。 ...