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

第7章. アプリケーションアーキテクチャの弱い点を特定する

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

これまで、ウェブアプリケーション内のコンポーネントを特定し、ウェブアプリケーション内の API の形状を決定し、ウェブアプリケーションがユーザのウェブブラウザとどのように対話することを期待しているかを学習するための、 テクニックをいくつか議論してきた。各テクニックはそれ自体で価値がありますが、それらから収集された情報が組織的な方法で組み合わされるとき、さら に多くの価値を得ることができます。

理想的なのは、先に提案したように、再調査のプロセスを通じて何らかのメモをとっておくことだ。ウェブアプリケーションの中には、その機能のすべてを探索するのに何ヶ月もかかるような拡張性を持つものがあるため、あなたの調査について適切な ドキュメントを作成することは不可欠である。偵察中に作成するドキュメントの量は、最終的にはあなた（テスター、ハッカー、趣味、エンジニアなど）次第であり、正しく優先順位をつけなければ、多ければ多いほど価値があるとは限らない。

テストするアプリケーションごとに、よく整理されたノートのセットを作成するのが理想的だ。これらのノートは、以下をカバーするものでなければならない：

• ウェブアプリケーションで使用されている技術

• HTTP動詞別APIエンドポイントリスト

• APIエンドポイントの形状のリスト（利用可能な場合）

• ウェブアプリケーションに含まれる関数（コメント、認証、通知など）

• ウェブアプリケーションが使用するドメイン

• 発見されたコンフィギュレーション（コンテンツ・セキュリティ・ポリシー[CSP]など）

• 認証／セッション管理システム

このリストを作成し終えたら、アプリケーションをハッキングしようとしたり、脆弱性を発見しようとしたりする場合に、優先順位をつけるために使うことができる。

一般に信じられていることに反して、ウェブ・アプリケーションの脆弱性のほとんどは、不適切に書かれたメソッドからではなく、 不適切に設計されたアプリケーション・アーキテクチャから生じている。確かに、ユーザが提供した HTML を直接 DOM に書き込むメソッドは間違いなく危険であり、ユーザがスクリプトをアップロードし（適切 なサニタイズが存在しない場合）、そのスクリプトを他のユーザのマシンで実行する（XSS）ことを許してしまうかもしれません。

しかし、世の中には何十もの XSS 脆弱性を持つアプリケーションがある一方で、同じ業界の他の同規模のアプリケーションはほぼゼロだ。結局のところ、アプリケーションのアーキテクチャと、そのアプリケーション内のモジュール/依存関係のアーキテクチャは、脆弱性 が発生する可能性のある脆弱点の素晴らしい指標となる。

安全なアーキテクチャ信号と安全でないアーキテクチャ信号の比較

が先に述べたように、単一のXSS脆弱性は、お粗末なメソッドの結果かもしれない。しかし、複数の脆弱性は、おそらくアプリケーションのアーキテクチャが脆弱であることの表れである。

ユーザが他のユーザにダイレクトメッセージ（テキスト）を送信できる2つの単純なアプリケーションを想像してみよう。これらのアプリケーションの一方は XSS に対して脆弱であり、もう一方は脆弱ではない。

安全でないアプリケーションは、APIエンドポイントにコメントを格納する要求が行われたときにスクリプトを拒否しないかもしれない。データベースはスクリプトを拒否しないかもしれないし、メッセージを表す文字列に対して適切なフィルタリングとサニタイズを実行しないかもしれない。最終的に、スクリプトはDOMにロードされ、DOM ...