Web アプリケーションセキュリティ

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

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

パートIの"Recon "では、ファーストパーティのウェブ・アプリケーションでサードパーティの依存関係を特定する方法（ ）を調査した。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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