WAFについて

先日、ゼミでWAFについて議論になったので、その件について紹介したいと思います。

そもそも、WAFとは何か。WAFとは、Web Application FIrewallの頭文字をとったもので、「ワフ」と言いますね。文字通り、Webアプリケーションを対象としたファイアウォールで、外部からのWebアプリケーションに対する不正な通信、具体的にはWebアプリケーションの脆弱性をついた攻撃を検出し、遮断します。Webアプリケーションの脆弱性といえば、クロスサイトスクリプティングとか、SQLインジェクションが有名ですね(他にもありますが)。例えば、ログイン画面に対するSQLインジェクションの入力といえば、' OR 'a'='aが認証回避に使われるものとして知られています。WAFはこういった攻撃とみなされる通信を検知してブロック(遮断)します。そのため、従来のWAFではこのような攻撃のパターンのリスト(またはルール)を持っていて、来た通信とパターンマッチングを行い、攻撃パターンにマッチする通信があればブロックします。
WAFは、アプリケーションの脆弱性そのものをなくす訳ではないので、本質的な対策ではないですが、応急措置や多重防御としては有効なので、導入する企業は多いです。

このようなWAFのポイントとしては2つ出てくると思います。1つは、どれだけ攻撃を見逃さずに検知できるか、つまり見逃し(検知漏れ、あるいはfalse negative)をどれだけなくせるかという点。もう一つは、攻撃ではなくアプリケーションに対する正規の通信なのに、攻撃として検知してしまう(誤検知、またはfalse positive)こともなくさないといけない点。特に誤検知があると、アプリケーションが正常なサービスができなくなってしまうので、致命的です。ただ、この2つをパターンマッチングによって完全になくせるかというと、微妙です。理由の一つは、攻撃、脆弱性の種類とそれぞれに応たパターンが無限に存在すること。それにいつ、新しい攻撃が出現するかもしれません。また、その攻撃が有効かどうかは、そのアプリケーションのフレームワークやデータベース実装、インフラ、アプリケーションの実装形態などによって違ってくるため、ある場合では攻撃となるものが、別の環境では正常通信となったりします。なので、WAFのパターンは常に新しい攻撃に対応するように更新が必要ですし、それぞれの環境に合わせる形で調整(チューニングといいます)が必要になります。このあたりは、アンチウィルスソフトの「パターンファイル」の問題と事情は同じですね。マルウェアの検知でも、パターンマッチングによる検知はもう限界と言われています。

ということで、最近では、AI時流にのって、AIを活用したWAFが登場してきているようです。例えば、既存のWAFに対応して、WAFの攻撃パターンのルール運用をAIで自動化してくれるサービスがあるようです。WafCharmや、ラックのサービスなどがそうです。また、サイバーセキュリティクラウド社では、WafCharmにAIエンジン「Cyneural」を搭載したクラウド型WAFの提供を開始しているようです。同様に、クラウド型WAFのシェアNo.1のScutumでも、異常検知アプローチのAI型WAFを提供しています。

WAFに関する研究では、Babuらの研究¹があります。Babuらは、DDoS、SQL インジェクション、XSSの検出ができるWAFを提案しています。DDoS攻撃は97.57% の精度、SQLi、XSS攻撃は89.34%の精度で検出しているとのことです。特徴は、3種の攻撃を分類するのに階層型アーキテクチャを用いている点です。つまり、まず1階層めでDDoSかどうかをみて、検出されなければ、次の階層でSQLインジェクションかどうかを判定…といっｔ具合です。それは、それぞれの階層で判定すれば、できるとは思いますが、それって新しいんですかね?時間がかかりそうなのも気になります。

ここで、このWAFの問題をとりあげた学生さんが、どのような点に関心があるかというと、彼はバイトでWAFを使っている際、たびたびの誤検出に悩まされているそうです。WAFは検出するだけで、リクエストのどの部分が問題となっているのか明示してくれません。現状ですらそうなので、これがAIによる検出となった時には更に問題となることを懸念しています。何しろAIは結果を出すだけで、どのような理由によってその判定に至ったのかは示してくれないからです。これはいわゆる、AIの説明可能性の問題ですね。なので、AIを使っても、誤検出した際にその理由が何なのか特定してくれるようなWAFの研究がしたいそうなんです。

ところが、この発表の際に、こんな議論になりました。発表の学生さんが、「検出の理由をインサイダーに示したい」と言ったことに対して、別の学生から「インサイダーに攻撃者がいた場合、開示した情報を用い、検出の回避に利用されるのでは?」という質問が出ました。なかなか面白いテーマだと思うので、ちょっと考えてみましょう。

本来は、攻撃者は外部にいて攻撃を行い、それが検知(遮断)されるかを観測可能です。ここで、攻撃者が内部にいて、検知理由が入手できたらどうなるか?

• 検知した攻撃が攻撃者が実際に実行した攻撃(x)と一致した場合(ケース(a))
  この場合、自分が攻撃した内容が検知されているということなので、回避手段の発見にはあまり役に立たないですね。
• 検知した攻撃が攻撃者が実際に実行した攻撃(x)と一致しない(別の攻撃(y)と一致)した場合
  • 攻撃者の攻撃(x)は検知できている場合(ケース(b))
    →ケース((a))と同じです。
  • 攻撃者の攻撃(x)としては検知できていない場合(ケース(c))
    →yとしては検知されないようにxの攻撃を工夫する可能性はあるけれども、これで成功するかは?です。

ということなので、それほど情報として役立っているかは疑問です。むしろ、攻撃者がWAFの情報を得られるインサイダーなら、データベースへのアクセスのリスクを考慮すべきではないでしょうか。

WAFについては、最近、生成系AIを用いた別のアプローチもあります。ルールや、テストデータ生成に生成系AIを用いるGPTFuzzer²のようなものです。「テストデータ」というのがキモで、これは攻撃リクエストになりうる訳です。こっちの方が、よほど問題になりうるのではないでしょうか?

1. Babu R. Dawadi,Bibek Adhikari and Devesh Kumar Srivastava, Deep Learning Technique-Enabled Web Application Firewall for the Detection of Web Attacks, MDPI Sensors, vol 23, Issue 4.2023 ↩︎
2. H. Liang et al., "Generative Pre-trained Transformer-Based Reinforcement Learning for Testing Web Application Firewalls," in IEEE Transactions on Dependable and Secure Computing .2023. ↩︎