狙われるWebアプリケーション、脆弱性対策とWAFに期待できることとは：守りが薄いWebアプリケーション（3）（1/2 ページ）

当連載ではWebアプリケーションのセキュリティが置かれている状況と、サイバー攻撃について具体的なデータを示し、防御策を紹介している。第1回と第2回ではWebアプリケーションの攻撃対象となる領域と、領域ごとの被害例に加えて、Webアプリケーションが攻撃を受けるまでにたどるプロセスについて簡単に整理した。今回は、Webアプリケーション側で可能な対策について脆弱性への対応とWAFを中心に解説していく。

[今井雅晴，＠IT]

連載：守りが薄いWebアプリケーション

Webセキュリティの対策を検討する前に考えることとは？

　これからWebアプリケーションのセキュリティについて本腰を入れて対策を始めようとしたときに、まずどこから手を付けようと考えるだろうか？

　「現状の把握」「公開される脆弱（ぜいじゃく）性情報のウォッチ」「脆弱性パッチの適用」「脆弱性診断／検査」「Webページ、サイト改ざんの検知」「WAF（Web Application Firewall）」に加え「それらの運用を今の人的リソースで回せるのか」などが挙がるだろう。

　これら全てを網羅的に対策できることがもちろん望ましい。しかし現実には、人員や予算、リスク、その他の要因があり、100点満点を取れる企業は多くないだろう。具体的にどのような手段で対策をとるかを考える前に、何点を目指す（何をどこまでやる）のか、目標を立てることも大事な要素であると筆者は考えている。

　連載第2回でも触れたように、インターネットに公開されているWebサイトは次のような特性を持っている。

• インターネットに公開しているシステムは、不特定多数からアクセスされる
• 守る側と攻撃側は、1対1ではなく、1対多となることを常に想定する必要がある

　防御側が圧倒的に不利な状況に加え、そもそも脆弱性のないシステムは存在しない。この前提に基づくと、例えば100％攻撃を防ぐことを目指すのではなく、どうすれば攻撃側のROI（投資対効果）を下げられるか（攻撃者に面倒くさいサイトだと思わせるか）という観点が浮かび上がる。「セキュリティ対策＝リスク低減策」と捉える上で、一つの現実的な考え方といえるだろう。

　Webサイトのセキュリティ対策を検討するに当たっては、インシデントの発生リスクを低減するための予防的対策が必要だ。加えて、インシデント（セキュリティ侵害）が発生した場合の一次対応と原因究明、復旧方法、その後の情報公開の体制などについてもプレイブック（基準および手順書）を用意しておくことが望ましい。

　今回はこのうちインシデントの発生リスクを低減するための予防策について考察していこう。

公表された脆弱性に即応できるとは限らない

　外部脅威によるセキュリティインシデントが発生するシステムには、何らかの脆弱性が存在する。では、システムに潜む脆弱性を平時にセキュリティ担当者がどのように認識するのかというと、次のようなパターンが考えられる。

脆弱性の発見方法
・未知の脆弱性の公表（例：利用しているミドルウェアで新たな脆弱性が公開される）
・脆弱性検査／ペネトレーションテストによる発見

　新たに発見された脆弱性に対して抜本的に対応するなら、OSやミドルウェアのバージョンアップやシステムパッチを施すことが望ましい。しかし、脆弱性公表後に即座に対応することが容易ではないケースも多い。次のような理由があるからだ。

• OSやミドルウェアの脆弱性は予告なく公開される
• サーバ保守作業の外注化などで、そもそも即座に作業できる体制が整っていない
• 改修作業に伴うシステム停止ができるか、判断基準が明確になっていない
• 作り込まれたアプリケーションでは、脆弱性改修が難しい。例えば、モジュールやミドルウェアの相互依存性チェックを踏まえた動作確認などに時間がかかる

　「公開された脆弱性が、自社のWebアプリケーションで悪用される可能性はあるか」という判断はシステムごとに違う。システム停止や改修作業をすべきか即座に判断でき、緊急度を判断できるスキルを有し、かつ実行に移せる組織やシステム管理者は、実際にはほんの一握りだろう。

脆弱性検査では空白期間に用心

　もう一つの方法である脆弱性検査／ペネトレーションテストでは、システム全体に潜む脆弱性を主に外部からの検査で洗い出す。アプリケーションのリリース前はもちろん、その後も定期的に実施することで、システムにできた“穴”をつぶすことができる。しかし、その検査結果だけから「安全宣言」を出すことは少々早計と言わざるを得ない。

　というのは、通常こうした脆弱性検査は、一定の周期（例えば半年に一度）で外部の専門家に委託して実施するからだ。一方で、それより早いペースで未知の脆弱性は日々公開されている。つまり、検査と検査の間の空白期間を埋める施策が必要になる。具体例を挙げてみよう。

　図1では、Oracleが2019年に公開したWebアプリケーションサーバ「Oracle WebLogic Server」の脆弱性を例にとった。定期的に実施する脆弱性検査と新たな脆弱性を使った攻撃との関係を時系列で示したものだ。

図1　Oracle WebLogic Serverの脆弱性を使った攻撃と脆弱性検査との関係

　このケースでは深刻度の高い脆弱性が2019年4月25日と同6月18日に、比較的短い間隔で公開されている。もし、WebLogic Serverを利用しているシステムの脆弱性検査が、その間の時期（例えば5月）に行われた場合、次の検査のタイミングが半年後なら11月となる。6月18日に公開された脆弱性を使った攻撃が7月に行われた場合、このシステムは「脆弱性検査をしたから安全性は確認済みだ」といえるだろうか？

　実際、新たな脆弱性を利用した攻撃は、情報公開後すぐに始まることが多い。つまり、検査と検査の間をつなぐ形で、継続的かつ速やかに対策を取る仕組みが必要だと分かるだろう。

攻撃実行までの各プロセスに対するWAFでの対応

　サーバをはじめとするシステムの停止やプログラム改修作業を待たずとも、速やかに新たな脆弱性に対処するために一般的に用いられているのが、Webアプリケーション攻撃を防御するWAF（Web Application Firewall）である。では、その役割を、「攻撃者が攻撃を行う際のプロセス」に沿って解説していこう。

　まず、連載第2回でも示した「攻撃者が攻撃を行う際のプロセス」を少しおさらいしてみる。一般にWebアプリケーション攻撃は以下の手順で進む。

1. 偵察行為（情報収集）
2. 脆弱性の発見
3. Webアプリケーションへの攻撃

「偵察行為」フェーズの傾向と対策

　偵察行為の通信には次のような特徴がある。

• TCPレベルの通信が多い――サーバ側の情報をWebプロトコルに限定せずに広く収集する
• HTTPレベルの通信が多い――Webアプリケーションの構成情報などを収集する

　一般的なWAFはこのうち、HTTP／HTTPSといったWebプロトコル以外のTCP通信をブロックする。つまりWAFを経由したTCPのポート番号80、ポート番号443以外の通信は、直接Webアプリケーションに届くことはない。つまり、最も単純な偵察行為を妨害できる。

　一方、HTTPレベルの情報収集では、大量のHTTPリクエストを送信してくる傾向があるため、単位時間当たりのリクエストレート数を調べて制御することで偵察行為を抑制できる。

　一部のWAFは「IPレピュテーション」機能を備えている。ビッグデータ解析によって、過去に脆弱性スキャニングや攻撃に悪用されたことのあるIPアドレスの危険度を判定して、リスクの高いIPからの通信を全てブロックする機能だ。

　ここで紹介したのはいずれも、「標的にされるネタとなる情報を与える」ことを阻止するものだ。

「脆弱性の発見」フェーズの傾向と対策

　2番目の「具体的な脆弱性を発見」するフェーズの通信には次のような特徴がある。

• HTTPレベルの通信が多い――HTTP通信でエラーが大量に発生する
• リクエストに攻撃コードが含まれている

　Webアプリケーションの脆弱性を発見するスキャニングでは、標的にどのような脆弱性があるかを確認するため、大量のHTTPリクエストを送り付ける傾向がある。このとき、Webサイトにとってイレギュラーなアクセスが増えるため、HTTPエラーの発生も多い。このことから、WAFによる対策としてはHTTPレスポンスのエラーをカウントするようなレート制御が有効である。

　さらに、脆弱性を発見するため、実攻撃と似たリクエストが送信される傾向もある。このため、WAFの攻撃検知ルールや、IPレピュテーションによる検知が効いて、阻止することも可能だろう。

「Webアプリケーションへの攻撃」フェーズの傾向と対策

　言うまでもなく、実際の攻撃に対してはWAFが備える全ての機能が有効である。

　Webアプリケーションに対する実攻撃を防御するための仕組みがWAFだと単純に捉えられがちだ。だが、ここまで順を追って示したように、偵察行為や脆弱性を見つけようとする行為に対しても、事態の進行を阻止して「狙われにくくする」対策が可能である。プロセスの段階が初期であればあるほど、対策の難易度を低く抑えることができる。つまり、図2に示したようにWAFによって偵察／情報収集を食い止めることが、効率的なセキュリティ対策につながる。

図2　偵察／情報収集フェーズは守りやすく、効果的