メニュー

WAFの基礎知識

WAFの基礎知識

著者:増井技術士事務所 代表 増井 敏克

少し古いWebアプリケーションを現在も使っているが、開発元の会社がもう存在していない。Webアプリケーションを狙った攻撃が高度化しているという話を聞くものの、どう対応していいのか分からない。脆弱(ぜいじゃく)性が見つかったが、すぐに修正できない。そんな中、少しでもセキュリティを高めるために、WAFを検討している人は多いでしょう。本連載では、全6回にわたりWAFの基礎知識について解説します。第1回は、実際にWAFを使うと、どのような効果があるのかを説明します。

第1回:WAF(Web Application Firewall)とは

1. Webアプリケーションの脆弱性

「コンピュータ、ソフトがなければただの箱」という言葉があるように、コンピュータを使うときにはソフトウェアが不可欠です。WindowsなどのOSだけでなく、WordやExcelといったオフィスソフト、WebブラウザやPDF閲覧ソフトに加えて、画像処理ソフトや年賀状作成ソフトなどを使っている人も多いでしょう。そして、インターネット経由で使用するWebアプリケーションも、ソフトウェアです。

便利なソフトウェアが多く開発されているなか、これらには、必ずといっていいほど不具合が存在します。Windowsなどのように大規模なソフトウェアでは、毎月のように修正プログラムが提供されています。また、スマートフォンアプリでも、機能追加だけでなく不具合の修正がよく行われます。利用者が想定している機能と異なる動作をするような不具合であれば誰もが気付きますが、不具合の内容はこれだけではありません。ここで取り上げるのは、セキュリティ上の不具合のことで、脆弱性と呼ばれます。多くの人は、その存在に気付くことはありません。しかし、攻撃者がそれに気付いて悪用すると、ウイルス感染や情報漏えい、改ざんなどさまざまな被害が発生します(図1)。

図1:不具合と脆弱性の違い

図1:不具合と脆弱性の違い(引用:増井敏克、図解まるわかりセキュリティのしくみ、翔泳社、2018年、P.97)

この脆弱性は、攻撃者だけでなく、セキュリティの研究者などが発見することもあります。その内容が開発者に報告されると、開発者が該当箇所を修正し、修正プログラムを公開します。利用者がこの修正プログラムを適用することで、問題点を解消できます。Windowsやスマートフォンアプリなどの場合は、端末内にあるアプリケーションに対して更新を適用するため、自動的に更新する仕組みを備えたものが増えてきました。

一方、Webアプリケーションの場合、Webブラウザから送信するリクエストに、攻撃者が悪意のあるコードを入力することで、不正な処理が実行されます。一般の利用者は、リクエストを送信して結果を受け取るだけなので、サーバ側に脆弱性が存在しても、対処できることはほとんどありません(図2)。

図2:Webアプリケーションでの不正な処理

図2:Webアプリケーションでの不正な処理(引用:増井敏克、おうちで学べるセキュリティのきほん、翔泳社、2015年、P.250)

セキュリティの研究者やサーバの管理者が脆弱性に気付き、不具合を修正する作業を行わないと、個人情報の漏えいや改ざんなどを防ぐことはできません。そこで必要になってくるのが、次に紹介する脆弱性診断であり、WAFなのです。

2. 脆弱性診断で守れるもの

ソフトウェアの開発時には、開発者がテストを行います。一般的なテストは、想定した操作が正しく動作することを確認する作業です。つまり、一般的な使用における不具合であれば、テストで検出できます。しかし、セキュリティ上の不具合である脆弱性は、検出できません。そこで、通常のテストに加えて、攻撃者の視点から脆弱性が残っていないかをチェックする作業が必要になります。これが、脆弱性診断です(図3)。今回は、Webアプリケーションに対する脆弱性診断を中心に解説しますが、実際にはデスクトップアプリやスマホアプリについても、脆弱性診断が行われます。

図3:脆弱性診断

図3:脆弱性診断(引用:増井敏克、図解まるわかりセキュリティのしくみ、翔泳社、2018年、P.113)

脆弱性診断には、ツールを使って機械的に実行する自動診断と、専門家が攻撃者の視点に立って手作業で試す手動診断があります。自動診断では、一般的によく使われる攻撃手法を、ツールが順に試します。フォームなどの入力欄に不正な文字を埋め込んだり、URLを書き換えたり、といった典型的な攻撃を順に試すことで、SQLインジェクションやクロスサイトスクリプティングなどの基本的な脆弱性であれば、漏れなく発見できます。SQLインジェクションやクロスサイトスクリプティングについては第5回で詳しく説明します。

ただし、人間にしか判断できない脆弱性も存在します。例えば、あるユーザーがログインしているときに、URLを書き換えるだけで他人がログインしている状況に変わってしまうような場合です。それが正しい動作なのか、コンピュータが判断することは困難です。また、特殊な作りになっているアプリケーションの場合、ツールでは見つけられないため、専門家が怪しいと思った部分を手作業で診断することもあります。このように、自動診断と手動診断を組み合わせて、さまざまな攻撃パターンを防御する必要があります。

3. WAFの効果

開発時に生じてしまう脆弱性は、開発者が気を付けていれば防ぐことができるのかもしれません。実際、脆弱性を少しでも減らすため、テストやレビューといった作業を行います。しかし、開発者も人間である以上、全ての脆弱性を取り除くことはできません。また、開発時は問題なくても、新しい攻撃手法の登場によって脆弱な部分ができてしまう可能性もあります。

自動診断や手動診断などの脆弱性診断を実施することで、多くの脆弱性を発見できます。それでも、実際には漏れがあるかもしれません。脆弱性が存在した場合、それを指摘することは簡単ですが、見つからないからといって存在しないとは言い切れないのです。「悪魔の証明」ともいわれるように、ないことを証明するのは難しいものです。脆弱性が見つかっても、修正できない場合があります。そのWebアプリケーションを開発した会社が既に存在しない、修正にかかる費用を工面できない、修正までに時間がかかるなど、さまざまな理由が考えられます。

そこで検討されるのが、WAF(Web Application Firewall)の導入です。WAFは名前のとおり、Webアプリケーションに特化したファイアウォールで、Webアプリケーションに対するさまざまな攻撃を防ぐために使われます。一般的なファイアウォールとは異なり、通信の中身をアプリケーションレベルで解析して防御できるのが特徴です。WAFを導入することで、脆弱性診断でのチェックに漏れた脆弱性を狙っての攻撃を防げる可能性があります。また、修正できない脆弱性があった場合にも、取りあえず一時的に導入する、という方法が考えられます。このため、脆弱性診断を行うことはもちろん必要ですが、さらにセキュリティを高めるという目的で、WAFを導入することが多くなっています(図4)。

図4:WAFを使う場面

図4:WAFを使う場面(引用:増井敏克、図解まるわかりセキュリティのしくみ、翔泳社、2018年、P.115)

~Tech Note編集部からのコメント~

いかがでしたか? 今回は、Webアプリケーションのセキュリティを高めるWAFについて説明しました。次回は、さまざまな種類のWAFを解説します。お楽しみに!

 

第2回:さまざまな種類のWAF

今すぐ、技術資料(第2回)をダウンロード!(無料)

前回は、Webアプリケーションの脆弱性やWAFの効果を説明しました。WAFの導入を検討するとき、どのようにWAFを選べばいいでしょうか。WAFには、その設置方法や設置場所によって、大きく3つの種類が存在します。それぞれにメリットとデメリットがあるため、導入コストやランニングコスト、利便性などを考えた上で、最適な種類を選ぶ必要があります。今回は、この3つの種類について解説します。

1. ソフトウェア型のWAF

WebアプリケーションはWebサーバ上で動作しているため、まずこのWebサーバにWAFを導入することが考えられます。つまり、WebサーバにインストールされたWAF機能を持つソフトウェアが、Webアプリケーションの実行時に、その通信内容をチェックする方法です。これが、ソフトウェア型のWAFです(図1)。コンピュータ内に導入されることから、ホスト型と呼ばれることもあります。

図1:ソフトウェア型のWAF(引用:独立行政法人情報処理推進機構セキュリティセンター、Web Application Firewall(WAF)読本、2011年、P.17)

図1:ソフトウェア型のWAF(引用:独立行政法人情報処理推進機構セキュリティセンター、Web Application Firewall(WAF)読本、2011年、P.17)

この方法のメリットは、ソフトウェアをWebサーバ内に導入するため、既存のネットワークに対する設定変更が不要なことです。WAFがどのように動作するのか、テスト的に少しだけ使ってみたい、という場合も、このソフトウェア型であれば手軽に試すことができます。一方で、サーバに導入するということは、それだけサーバの負荷が増えることを意味します。Webアプリケーションの場合、個々の処理はそれほど負荷の高いものではありません。しかし、短期間に大量のアクセスがあると、それぞれに対してのチェックが頻繁に実行されるため、サーバへの負荷が当初の想定を大きく上回り、性能が低下してしまう可能性があります。

また、Webサーバは1台だけとは限りません。サーバの台数が多ければ、それだけ導入や設定作業といった手間がかかるだけでなく、ライセンス費用が高額になることも考えられます。さらに、サーバへの導入だけでなく、最適に運用するための適切な設定を行うには、専門的な知識が求められます。

2. ネットワーク型のWAF

Webサーバの負荷を増やしたくない、Webサーバに新たなソフトウェアを導入することは避けたい、という場合は、専用の機器を設置する方法が考えられます。Webアプリケーションが動作しているWebサーバと、インターネットとの間にある経路上に導入する方法で、ネットワーク型と呼ばれます(図2)。または、アプライアンス型、ゲートウェイ型と呼ばれることもあります。

図2:ネットワーク型のWAF(引用:独立行政法人情報処理推進機構セキュリティセンター、Web Application Firewall(WAF)読本、2011年、P.16)

図2:ネットワーク型のWAF(引用:独立行政法人情報処理推進機構セキュリティセンター、Web Application Firewall(WAF)読本、2011年、P.16)

ファイアウォールという役割を考えると、中間に設置するのはイメージとして分かりやすいかもしれません。実際には、WAF専用のハードウェアで構成されるものだけでなく、汎用のサーバにWAFのソフトウェアを導入する方法もあります。いずれにしても、ネットワーク構成の上では、スイッチやルータのように、通信の橋渡しを行うかたちで設置します。

続きは、保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。

3. 運用を任せられるクラウド型のWAF

保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。

今すぐ、技術資料(第2回)をダウンロード!(無料)

 

第3回:他のセキュリティ技術との違い

今すぐ、技術資料(第3回)をダウンロード!(無料)

前回までの連載で、Webアプリケーションを狙った攻撃を防ぐために、WAFが有効だということが分かりました。一方、他のセキュリティ技術を導入していれば、WAFの導入は不要ではないか、と考える人もいるかもしれません。しかし、それぞれのセキュリティ技術では、防げる攻撃の種類や守るべき内容が異なります。どのような違いがあるのか、今回は、その特徴について解説します。

1. ファイアウォールとの違い

名前が似ていることから、よくWAFと混同される技術に、ファイアウォールがあります(図1)。いずれも、外部からの攻撃を防ぐために使われ、特にネットワークに対する攻撃を防ぐために設置されるのが、ファイアウォールです。例えば、サーバの空きポートを順に調べるポートスキャンを行ったり、本来アクセスできないサーバへの不正アクセスを防いだりすることができます。

図1:ファイアウォール(引用:増井敏克、おうちで学べるセキュリティのきほん、翔泳社、2015年、P.72)

図1:ファイアウォール(引用:増井敏克、おうちで学べるセキュリティのきほん、翔泳社、2015年、P.72)

ファイアウォールでチェックするのは、主にIPアドレスやポート番号のような、ネットワークにおける通信の宛先や、発信元の情報です。ネットワークでの通信を郵便物に例えると、ファイアウォールは、差出人や宛先の住所や名前をチェックするだけで、その郵便物の中身をチェックすることはありません。このため、SQLインジェクションやクロスサイトスクリプティングなどの、Webアプリケーション(ソフトウェア)に対する攻撃を防ぐことはできません。これらの攻撃では、公開されているWebサーバに対して、通常のアクセスを少しだけ変えるといった処理を行います。つまり、郵便物の中身をチェックする必要があるため、ここでWAFの出番となります。WAFは、フォームやURLに対して入力された内容をチェックし、一般的に攻撃と判断されるような通信を拒否します。このため、ファイアウォールとは別に、WAFの導入が必要となるのです。

2. IPSやIDSとの違い

ファイアウォールと同様に、ネットワークに対する外部からの攻撃を防ぐ機器が、IPSやIDSです。IPSは不正侵入防止システム、IDSは不正侵入検知システムと呼ばれ、それぞれ外部からの不正侵入を防御・検知する機能があります。名前のとおり、IDSが不正なアクセスを検知して管理者に通知するだけなのに対し、IPSは不正なアクセスを検知すると、その通信を遮断するなど、侵入を防ぐ処理を行います(図2)。

図2:IPSでの通信の遮断(引用:増井敏克、おうちで学べるセキュリティのきほん、翔泳社、2015年、P.175)

図2:IPSでの通信の遮断(引用:増井敏克、おうちで学べるセキュリティのきほん、翔泳社、2015年、P.175)

ここでいう不正侵入とは、DoS攻撃やSYN Flood攻撃など、目標のサーバに大量のパケットを送信し、サーバの正常な動作を妨害する攻撃を指します。このとき、通信内容を1つずつチェックしても、通信の宛先や発信元には問題がないため、ファイアウォールでは防げません。そして、その量が大量になった場合、サーバやネットワークに大きな負荷がかかり、サーバがダウンしたり、通信を正常に処理できなくなったりします。

続きは、保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。

3. ウイルス対策ソフトとの違い

保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。

今すぐ、技術資料(第3回)をダウンロード!(無料)

 

第4回:WAFの検知方法

今すぐ、技術資料(第4回)をダウンロード!(無料)

前回は、WAFとその他のセキュリティ技術との違いを説明しました。Webアプリケーションを狙った攻撃パターンは多岐にわたるため、その全てをWAFで検知することは決して容易ではありません。次々と登場する新たな攻撃に対応するには、検知するパターンのメンテナンスが必要になります。今回は、実際にWAFが行っている検知方法と、さまざまな運用や監視の手法、およびその最近のトレンドについて紹介します。

1. ブラックリスト方式

不正な入力をチェックしたいとき、まず思いつくのは、その入力に共通する要素を調べる方法でしょう。例えば、フォームにHTMLのタグが入力された場合に問題が発生するのであれば、HTMLのタグを入力できないようにすれば良いのです。このように、不正と判断される攻撃パターンのリストを用意しておき、その内容と一致する処理が行われた時にブロックする、もしくは無害化する方法を、ブラックリスト方式といいます。

身近でブラックリストという言葉を耳にするのは、クレジットカードを作成したり、ローンを組んだりする場面です。過去に延滞の発生や破産などによって信用が失われた場合、ブラックリストが発生します。そこに掲載されている人は、クレジットカードの作成やローンの申し込みができなくなります。

WAFでのブラックリストも同様で、そこに登録された攻撃パターンに対し、その通信を拒否したり無害化したりします。登録した攻撃パターンと一致する攻撃は全て排除できるため、確実な手法ではあるものの、リストのメンテナンスを継続的に行う必要があります。新たな攻撃手法は次から次へと発生しているため、このブラックリストへの登録作業が頻繁に発生します。もし、防ぐべき攻撃手法の登録が漏れてしまうと、その攻撃を防ぐことはできません。逆に、正常な処理内容であっても、誤ってリストに登録されることで、実行できなくなってしまいます。

2. ホワイトリスト方式

ブラックリスト方式とは逆に、正常と判断される通信のみを許可する方法を、ホワイトリスト方式といいます。リストに登録されているもの以外は許可しないため、新たな攻撃パターンの発生にも影響を受けません。さらに、最初に適切なリストを作成しておけば、そのWebアプリケーションの仕様が変わらない限り、リストの更新作業は必要ありません。ただし、入力可能なパターンとして、文字の種類や文字数、入力形式など、全ての正常パターンを最初に登録する必要があるため、その作成には時間がかかります。実際には、ホワイトリスト作成機能を持つ製品があるため、一般的な通信を何度か繰り返すことで、そこに共通する内容を元に、WAFがリストを自動生成してくれます。こうした機能を使うことで、管理コストを削減できる可能性があります。

こうした簡便性から、ホワイトリスト方式の方がブラックリスト方式よりも人気を集めているようです。とはいえ、ホワイトリストとして定義できないような場面も存在するため、どちらが良いということはなく、アプリケーションの特徴に応じて使い分ける必要があります(表1)。

なお、Webアプリケーションの仕様変更や機能追加が発生した場合、ホワイトリストの定義を見直す必要があることを忘れてはいけません。ブラックリストやホワイトリストという言葉は、子ども向けのフィルタリングソフトなどで使われることもあります。これらは、利用者側に設置して、利用可能なWebサーバを判断するために使われます。しかし、WAFの場合は、サーバ側に設置して通信内容をチェックする、という違いがあります。

表1:ブラックリストとホワイトリストの違い(引用:独立行政法人情報処理推進機構セキュリティセンター、Web Application Firewall(WAF)読本、2011年、P.20)https://www.ipa.go.jp/files/000017312.pdf

表1:ブラックリストとホワイトリストの違い

3. パターンマッチングとAIの活用

保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。

今すぐ、技術資料(第4回)をダウンロード!(無料)

 

第5回:WAFで守れる攻撃の例

今すぐ、技術資料(第5回)をダウンロード!(無料)

前回は、WAFの検知方法を説明しました。WAFの導入に当たって、具体的にどのような攻撃を防げるのか分からない、そもそも自社のシステムにWAFが必要なのか、という疑問を持つ人も多いのではないでしょうか。Webアプリケーションはさまざまな攻撃を受けます。今回は、特にWebアプリケーションに対してよく使われる攻撃方法と、WAFがどのようにしてこれを防ぐのかについて解説します。

1. SQLインジェクション

ショッピングサイトやSNS、掲示板、検索エンジンなど多くのWebアプリケーションでは、データの保存にデータベースを使用します。こうしたWebアプリケーションでは、SQLという言語を使ってデータベース管理システムを操作します。プログラムの中でこのSQLの記述方法に問題があると、攻撃者が特殊な記述内容を送信してSQLに攻撃コードを埋め込むことで、開発者の想定していない指示を出すことができてしまいます。これにより、データベースの破壊や、個人情報の抜き出しなどが可能になります。

このように、不正な指示をSQLの中に注入する(インジェクション)ものが、SQLインジェクションという攻撃方法です。例えば、ログイン画面のあるWebアプリケーションがあります。入力したIDとパスワードが一致すればログインできる仕組みで、一般的な使い方であれば問題なく動作します。しかし、パスワードの欄に図1のような値を入力することで、IDさえ分かっていれば、パスワードを知らなくてもログインできてしまいます。

図1:SQLインジェクションの例(引用:増井敏克、おうちで学べるセキュリティのきほん、翔泳社、2015年、P.260)

図1:SQLインジェクションの例(引用:増井敏克、おうちで学べるセキュリティのきほん、翔泳社、2015年、P.260)

このとき、Webアプリケーションの中では、次のようなSQLが実行されていました。

ここに、上記のパスワードが入力されると、パスワード認証の部分が無視され、ログインできてしまったのです。これが、SQLインジェクションです。「’」のような記号が入力可能になっている場合、それがSQL文として意味を持ってしまうことが問題になります。パスワード入力欄に図1の値を入力すると、実際に発行されるSQLは次のような内容になります。

ここで、最後の「’a’ = ‘a’」という条件は常に成り立つため、パスワードが何であってもログインできてしまうのです。

SQLインジェクションを防ぐには、入力欄に含まれる「’」などの不適切な文字を、エラーと判断させる方法が考えられます。これは、WAFのブラックリストなどに、パスワードとして不適切な文字を登録しておくことで可能になります。

2. クロスサイトスクリプティング

掲示板など、利用者投稿型のWebアプリケーションでは、利用者が入力した内容を他の人が閲覧できます。とても便利な仕組みである反面、利用者がHTMLの構文を含んだ内容を入力し、それをそのまま出力した場合は、問題が発生します。一般の利用者にとって、自由に好みのフォントや画像を投稿できるHTMLは便利なものです。しかし、攻撃者はスクリプトと呼ばれるプログラムを投稿できてしまいます。

続きは、保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。

3. クロスサイトリクエストフォージェリ

保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。

今すぐ、技術資料(第5回)をダウンロード!(無料)

 

第6回:WAFの注意点

今すぐ、技術資料(第6回)をダウンロード!(無料)

前回は、WAFで守れる攻撃の例について説明しました。最終回となる今回は、実際にWAFを導入した後で、具体的にどのような運用や監視作業が発生するのか、その注意点を解説します。WAFは、導入すればそれで終わりではありません。攻撃手法は次々に変化するため、Webアプリケーションの仕様変更や機能追加も発生します。これらに合わせたチューニングが必要であり、サーバの負荷や出力されるログなども監視しなければなりません。

1. 誤検知の発生

WAF の誤検知には、偽陽性と偽陰性があります。まず、この2つについて説明します。WAFを導入すると、攻撃を検知した場合に通信を遮断します。これが、実際の攻撃に対しての遮断であれば問題はありません。しかし、攻撃ではないのに遮断してしまう場合があります。つまり、一般の利用者が通常の使い方をしているにもかかわらず、誤検知が発生して遮断してしまうことがあるのです。これを、偽陽性(フォールス・ポジティブ)といいます。このような場合、利用者から問い合わせがあれば問題ありませんが、必ずしもそうとは限りません。重要な顧客が、この誤検知を不審に思わず、単にシステムが使えないという理由で離れてしまう可能性もあります。

逆に、攻撃者が攻撃を仕掛けたのに、WAFが問題のない通信と判断し、通過させてしまう場合もあります。これは、設定しているブラックリストやホワイトリストの内容に誤りがある、WAFの機能不足で必要なチェックができていない、などの原因が考えられます。管理者は防御しているつもりでも、実際にはその役目を果たしていないのです。これを、偽陰性(フォールス・ネガティブ)といいます(図1)。

このような誤検知が発生していないか、WAFのログなどをチェックし、速やかに対応する必要があります。また、定期的にブラックリストやホワイトリストの内容を見直し、適切な設定に修正しなければなりません。このとき、リストの見直しによって新たに偽陽性や偽陰性が発生しないように、検証パターンの検証手順や更新手順について整理しておきましょう。

図1:偽陽性と偽陰性

図1:偽陽性と偽陰性(引用:独立行政法人情報処理推進機構セキュリティセンター、Web Application Firewall(WAF)読本、2011年、P.28)https://www.ipa.go.jp/files/000017312.pdf

2. チューニングに必要な運用コスト

WAFを導入するときに忘れられがちなのが、運用にかかるコストです。一般的には、WAF製品の価格や動作検証にかかる人件費といった、導入時のコストに意識が向けられます。WAFの手法であるソフトウェア型、ネットワーク型、クラウド型など、その機能面に注目することもあるものの、いずれの場合でも、WAFを導入して終わりというわけではありません。

WAFの運用形態がブラックリスト方式かホワイトリスト方式かにかかわらず、そのリストのメンテナンスは必須です。新しい攻撃手法が登場した場合に限らず、Webアプリの仕様変更や機能追加などが発生するたびに、新たな見直しが必要になります。このとき、WAFの保守コストや運用コストを考える必要があるのです。特に、ログの確認やリストの更新といった運用にかかる人件費は、期間が長くなるほど大きくなります。

続きは、保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。

3. サーバへの影響

保管用PDFに掲載中。ぜひ、下記よりダウンロードして、ご覧ください。

今すぐ、技術資料(第6回)をダウンロード!(無料)

    ピックアップ記事

    tags