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

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

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

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

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

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

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

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

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

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

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

• 発見された設定（コンテンツ・セキュリティ・ポリシーやCSPなど）

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

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

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

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

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

前述したように、 XSSの脆弱性が1つだけあるのは、メソッドの書き方が悪いせいかもしれない。しかし、複数の脆弱性は、おそらくアプリケーションアーキテクチャが脆弱であることの表れである。

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

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