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

第36章. ビジネスロジックの脆弱性を軽減する

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

第18章では、とらえどころのないビジネスロジックの脆弱性について述べた。これは、自動化では容易に発見できず、侵入テストでも容易に発見できない、高度な脆弱性である。

ビジネスロジックの脆弱性 通常、アプリケーションのビジネスロジックに関する深い知識を必要とし、そのため攻撃はより困難である。 幸運なことに、このような脆弱性を理解するためには、深い工学的知識が必要とされることが多いので、このような 脆弱性に対する防御は、攻撃するよりもかなり簡単である。

セキュリティチームがエンジニアリングチームと緊密に連携していることを前提とすると、ビジネスロジックの脆弱性を緩和し、アプリケーションを保護することに関して、セキュリティチームは実際に有利になります。この章では、ビジネスロジックの脆弱性を防止し、緩和するメソッドについて説明します。

アーキテクチャレベルの緩和策

ビジネスロジックの脆弱性を緩和するための最も重要なステップは、アプリケーションコードが書かれる前のアーキテクチャ の段階で発生します。伝統的なウェブアプリケーションのアーキテクチャ設計では、 意図されたユーザは、意図されたユースケースとともに考慮される。

他の多くの技術領域では、 ワーストケースシナリオの設計に価値があることがすでに確認されているからである。アプリケーションのセキュリティのために、この原則をどのように使うことができるかを議論する前に、ワーストケース設計の利点を示す、次の例を評価しよう。

Big-O時間の中央値(n)で実行されるアルゴリズム(A1)のプログラミングの場合を考える。アルゴリズムA1への入力として5つの要素が与えられると、このアルゴリズムは中央値C = 5の実行時間を持つことが推論できる。

しかし、10回中1回のアルゴリズムがn^2のランタイムを持つとすると、5つの要素では、最悪のシナリオでC=25のランタイムが残る。他のすべての実行が中央値C = 5の実行時間で終わる場合、5時間の実行が9回、25時間の実行が1回ある。これを表36-1に示す。

表36-1. アルゴリズムA1のランタイム

出走番号	ランタイム	走行時間の中央値	平均走行時間
1	5	5	5
2	5	5	5
3	5	5	5
4	5	5	5
5	5	5	5
6	5	5	5
7	5	5	5
8	5	5	5
9	5	5	5
10	25	5	7

この結果、A1アルゴリズムの10回の試行における平均実行時間は、(9 × 5 + 25)/10 = 7となった。実行時間の中央値はやはり5である。

初期化可能な2つのアルゴリズム、A1（先ほど見た）とA2があったとしよう。中央値評価を使ったそれぞれのスペックは以下の通りだ：

• A1中央値：5

• A2中央値：6

中央値に基づいて評価するアプローチでは、A1がより良い選択肢であると仮定する。しかし、掘り下げてA2が常に一定の速度6で走っていることを理解すれば、時間の経過とともにA1は7に向かう傾向にあり、A1より16％効率が悪いことがわかる。

この はベストケース設計の例である。優れたセキュリティ・アーキテクトは、決してベストケース設計を用いず、常にワーストケース設計を用いる。

もしITアーキテクトがA1アルゴリズムを選択したとしたら、エッジケースが発生するまでは、このアプリケーションではA2よりも高速に実行されるだろう。何度も繰り返すうちに、そのようなエッジケースが発生すると、A1がA2に比べて遅くなり、A2がA1より速くなる。 ...