回答編集履歴
1
コメントに対する回答を追記しました
answer
CHANGED
|
@@ -6,4 +6,31 @@
|
|
|
6
6
|
|
|
7
7
|
であり、これらはご検知が見つかった時点では既知となっていないわけです。
|
|
8
8
|
したがって、「この環境にはOSコマンドインジェクション脆弱性がないからOSコマンドインジェクションのシグネチャは無効化しても大丈夫」と判断しても、その後新たにOSコマンドインジェクション脆弱性が発見されたタイミングでは、WAFが対応できないことになります。そういう場面こそWAFに働いて貰いたいわけです。
|
|
9
|
-
なので、shoko1さんが既に指摘されているように、プロに任せた方がよろしいかと思います。
|
|
9
|
+
なので、shoko1さんが既に指摘されているように、プロに任せた方がよろしいかと思います。
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
コメントいただいた内容に対して、長くなりますので、回答本文に追記いたします。
|
|
13
|
+
|
|
14
|
+
> 誤検知で業務影響で出ているのにWAF側で何も対応しない訳にはいかないと思います。
|
|
15
|
+
|
|
16
|
+
その通りです。なので基本的に誤検知のでるシグネチャは無効化しますが、
|
|
17
|
+
|
|
18
|
+
まず、サイト全体にわたって当該シグネチャを無効化するかどうかを検討します。
|
|
19
|
+
通常シグネチャが誤検知するのは特定ページ(URL)だけですので、WAFにもよるでしょうが該当URLだけ無効化できれば、無効化による防御力低下を緩和できます。
|
|
20
|
+
|
|
21
|
+
次に、シグネチャ無効化による防御力低下が許容範囲かどうかを確認します。
|
|
22
|
+
|
|
23
|
+
たとえば、たまたまStruts2の脆弱性に対するシグネチャが誤検知していて、当該サイトでStruts2を使っていない場合であれば、そのシグネチャを無効化することによる防御力低下は無視できます。
|
|
24
|
+
また、SQLインジェクション脆弱性のシグネチャ（の一つ）が誤検知していても、当該サイトでSQLを使っていない場合は同様です。
|
|
25
|
+
|
|
26
|
+
私が過去に経験した例では、バランサーがクッキーに100%という値をセットしていて、これがWAFで誤検知した例があります。100%はパーセントエンコード（URLエンコード）として見た場合不正な値だからという理由です。しかし、当該サイトはクッキーにはセッションIDしか入っておらず、不正なパーセントエンコードによる攻撃はできないだろうという判断から当該シグネチャは単に無効化しました。何らかの理由で無効化では不安な場合は、(1)ホワイトリストによるチェックを追加する、(2)クッキー値が「100%」という値の場合のみ当該シグネチャを無視するというルールを追加する、等の運用が考えられます。
|
|
27
|
+
|
|
28
|
+
また、当該脆弱性のシグネチャが複数あり、そのうちの一つのみが誤検知している場合は、他のルールで十分守れると判断すれば、当該シグネチャを単に無効化します。
|
|
29
|
+
|
|
30
|
+
また、CMSのサイトによくありますが、特定シグネチャが管理者ページで誤検知するが、当該ページはBASIC認証で保護されていて外部からの攻撃は想定しなくて良い場合は、管理者ページ全体で当該シグネチャを無効化するという作戦も考えられます。
|
|
31
|
+
|
|
32
|
+
最後に、上記のような無効化戦略が使えない場合はやっかいです。
|
|
33
|
+
私の経験では、フランス語を扱うサイトで、語尾が「'or」で終わるフランス語単語が誤検知する例がありました。これは単に無効化は危険だと思われたので、当該シグネチャを無効化する代わりに、ORを含む攻撃を防御し、かつ誤検知しないカスタムシグネチャを追加しました。
|
|
34
|
+
|
|
35
|
+
このように、誤検知対処はケースバイケースであり、フローチャートにより機械的に対応することは難しいのではないかと考えます。
|
|
36
|
+
|