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

第15章. サードパーティの依存関係を利用する

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

今日のソフトウェアがOSSの上に構築されていることは周知の事実だ。商業的な分野でさえ、最大かつ最も収益性の高い製品の多くは、世界中の多くの開発者によるオープンソースの貢献の上に構築されている。

OSSの上に構築された製品には次のようなものがある：

• Reddit (BackBoneJS、Bootstrap)

• Twitch (Webpack、Nginx)

• YouTube（ポリマー）

• LinkedIn (EmberJS)

• Microsoft Office Web (AngularJS)

• Amazon DocumentDB (MongoDB)

単にOSSに依存するだけでなく、現在では多くの企業が主力製品をオープンソース化し、製品を直接販売する代わりにサポートや継続的なサービスで収益を上げている。その例をいくつか挙げよう：

• オートマティック社（ワードプレス）

• キヤノニカル（Ubuntu）

• シェフ

• Docker（ドッカー）

• Elastic（Elasticsearch）。

• モンゴ（MongoDB）

• GitLab（ギットラボ）

BuiltWithはウェブ・アプリケーションの一例で、他のウェブ・アプリケーションがどのような技術に基づいて構築されているかを判断するために、他のウェブ・アプリケーションをフィンガープリントする（図15-1）。これはウェブ・アプリケーションの背後にあるテクノロジーを素早く判断するのに便利である。

図15-1. BuiltWithウェブ・アプリケーション

OSSへの依存は、便利ではあるが、しばしば重大なセキュリティリスクをもたらす。このリスクは、機知に富んだ戦略的なハッカーに悪用される可能性がある。OSS がアプリケーションのセキュリティのリスクになり得る理由はいくつかあり、そのすべてに注意を払うことが重要である。

まず第一に、OSSに依存するということは、おそらく自社のコードと同じような厳重な監査が行われていないコードベースに依存することを意味する。大規模なOSSのコードベースを監査するのは非現実的である。まず、セキュリティ・エンジニアを十分に増強してコードベースに精通させる必要があり、その後、コードの詳細なポイント・イン・タイム分析を実施する必要があるからだ。これは非常にコストのかかるプロセスである。

OSSのコードベースは常に更新されるからである。理想的には、送られてくるプルリクエストごとにセキュリティ評価を行うことである。残念ながら、それも非常に高価なことであり、ほとんどの企業はそのような金銭的な損失には協力せず、むしろ比較的不慣れなソフトウェアを使用するリスクを負うことになるだろう。

これらの点から、OSSの統合や依存関係は、誰かのソフトウェアに侵入しようとするハッカーにとって格好の出発点となる。鎖は最も弱い鎖ほど強く、最も弱い鎖は最も厳密でない品質保証を受けた鎖であることが多い。

ハッカーとして、悪用すべきOSSの統合や依存関係を発見する最初のステップは、偵察である。偵察の後、これらの統合の悪用可能性はさまざまな角度からやってくる。 ...