少し古いWebアプリケーションを現在も使っているが、開発元の会社がもう存在していない。Webアプリケーションを狙った攻撃が高度化しているという話を聞くものの、どう対応していいのか分からない。脆弱(ぜいじゃく)性が見つかったが、すぐに修正できない。そんな中、少しでもセキュリティを高めるために、WAFを検討している人は多いでしょう。本連載では、全6回にわたりWAFの基礎知識について解説します。第1回は、実際にWAFを使うと、どのような効果があるのかを説明します。
「コンピュータ、ソフトがなければただの箱」という言葉があるように、コンピュータを使うときにはソフトウェアが不可欠です。WindowsなどのOSだけでなく、WordやExcelといったオフィスソフト、WebブラウザやPDF閲覧ソフトに加えて、画像処理ソフトや年賀状作成ソフトなどを使っている人も多いでしょう。そして、インターネット経由で使用するWebアプリケーションも、ソフトウェアです。
便利なソフトウェアが多く開発されているなか、これらには、必ずといっていいほど不具合が存在します。Windowsなどのように大規模なソフトウェアでは、毎月のように修正プログラムが提供されています。また、スマートフォンアプリでも、機能追加だけでなく不具合の修正がよく行われます。利用者が想定している機能と異なる動作をするような不具合であれば誰もが気付きますが、不具合の内容はこれだけではありません。ここで取り上げるのは、セキュリティ上の不具合のことで、脆弱性と呼ばれます。多くの人は、その存在に気付くことはありません。しかし、攻撃者がそれに気付いて悪用すると、ウイルス感染や情報漏えい、改ざんなどさまざまな被害が発生します(図1)。
図1:不具合と脆弱性の違い(引用:増井敏克、図解まるわかりセキュリティのしくみ、翔泳社、2018年、P.97)この脆弱性は、攻撃者だけでなく、……
>>第1回 第1章の続きを読む(PDFダウンロード)
ソフトウェアの開発時には、開発者がテストを行います。一般的なテストは、想定した操作が正しく動作することを確認する作業です。つまり、一般的な使用における不具合であれば、テストで検出できます。しかし、セキュリティ上の不具合である脆弱性は、検出できません。そこで、通常のテストに加えて、攻撃者の視点から脆弱性が残っていないかをチェックする作業が必要になります。これが、脆弱性診断です(図3)。今回は、Webアプリケーションに対する脆弱性診断を中心に解説しますが、実際にはデスクトップアプリやスマホアプリについても、脆弱性診断が行われます。
図3:脆弱性診断(引用:増井敏克、図解まるわかりセキュリティのしくみ、翔泳社、2018年、P.113)脆弱性診断には、ツールを使って機械的に実行する自動診断と、専門家が攻撃者の視点に立って手作業で試す手動診断があります。自動診断では、……
>>第1回 第2章の続きを読む(PDFダウンロード)
開発時に生じてしまう脆弱性は、開発者が気を付けていれば防ぐことができるのかもしれません。実際、脆弱性を少しでも減らすため、テストやレビューといった作業を行います。しかし、開発者も人間である以上、全ての脆弱性を取り除くことはできません。また、開発時は問題なくても、新しい攻撃手法の登場によって脆弱な部分ができてしまう可能性もあります。
自動診断や手動診断などの脆弱性診断を実施することで、多くの脆弱性を発見できます。それでも、実際には漏れがあるかもしれません。脆弱性が存在した場合、それを指摘することは簡単ですが、見つからないからといって存在しないとは言い切れないのです。「悪魔の証明」ともいわれるように、ないことを証明するのは難しいものです。脆弱性が見つかっても、修正できない場合があります。そのWebアプリケーションを開発した会社が既に存在しない、修正にかかる費用を工面できない、修正までに時間がかかるなど、さまざまな理由が考えられます。
そこで検討されるのが、WAF(Web Application Firewall)の導入です。WAFは名前のとおり、……
>>第1回 第3章の続きを読む(PDFダウンロード)
前回は、Webアプリケーションの脆弱性やWAFの効果を説明しました。WAFの導入を検討するとき、どのようにWAFを選べばいいでしょうか。WAFには、その設置方法や設置場所によって、大きく3つの種類が存在します。それぞれにメリットとデメリットがあるため、導入コストやランニングコスト、利便性などを考えた上で、最適な種類を選ぶ必要があります。今回は、この3つの種類について解説します。
WebアプリケーションはWebサーバ上で動作しているため、まずこのWebサーバにWAFを導入することが考えられます。つまり、WebサーバにインストールされたWAF機能を持つソフトウェアが、Webアプリケーションの実行時に、その通信内容をチェックする方法です。これが、ソフトウェア型のWAFです(図1)。コンピュータ内に導入されることから、ホスト型と呼ばれることもあります。
図1:ソフトウェア型のWAF(引用:独立行政法人情報処理推進機構セキュリティセンター、Web Application Firewall(WAF)読本、2011年、P.17)この方法のメリットは、……
>>第2回 第1章の続きを読む(PDFダウンロード)
Webサーバの負荷を増やしたくない、Webサーバに新たなソフトウェアを導入することは避けたい、という場合は、専用の機器を設置する方法が考えられます。Webアプリケーションが動作しているWebサーバと、インターネットとの間にある経路上に導入する方法で、ネットワーク型と呼ばれます(図2)。または、アプライアンス型、ゲートウェイ型と呼ばれることもあります。
図2:ネットワーク型のWAF(引用:独立行政法人情報処理推進機構セキュリティセンター、Web Application Firewall(WAF)読本、2011年、P.16)ファイアウォールという役割を考えると、中間に設置するのはイメージとして分かりやすいかもしれません。実際には、……
>>第2回 第2章の続きを読む(PDFダウンロード)
ソフトウェア型のWAFや、ネットワーク型のWAFのデメリットを解消する方法として、最近人気を集めているのがクラウド型のWAFです。自社で運用・監視が必要な前述のWAFに比べ、クラウド型のWAFであれば、外部の専門家に運用を任せられるだけでなく、月額の利用料だけで運用できるというメリットがあります。導入にかかる時間も短く、すぐに利用を開始できます。自社で管理しているWebサーバへのアクセスを、クラウド型のWAFを経由するようネットワーク設定を変更するだけなので、新たなハードウェアやソフトウェアを導入する必要もありません。ネットワーク型のWAFで導入するハードウェアの代わりに、サービスとして利用するイメージです。
ただ、こうしたメリットの一方、……
>>第2回 第3章の続きを読む(PDFダウンロード)
前回までの連載で、Webアプリケーションを狙った攻撃を防ぐために、WAFが有効だということが分かりました。一方、他のセキュリティ技術を導入していれば、WAFの導入は不要ではないか、と考える人もいるかもしれません。しかし、それぞれのセキュリティ技術では、防げる攻撃の種類や守るべき内容が異なります。どのような違いがあるのか、今回は、その特徴について解説します。
名前が似ていることから、よくWAFと混同される技術に、ファイアウォールがあります(図1)。いずれも、外部からの攻撃を防ぐために使われ、特にネットワークに対する攻撃を防ぐために設置されるのが、ファイアウォールです。例えば、サーバの空きポートを順に調べるポートスキャンを行ったり、本来アクセスできないサーバへの不正アクセスを防いだりすることができます。
図1:ファイアウォール(引用:増井敏克、おうちで学べるセキュリティのきほん、翔泳社、2015年、P.72)ファイアウォールでチェックするのは、……
>>第3回 第1章の続きを読む(PDFダウンロード)
ファイアウォールと同様に、ネットワークに対する外部からの攻撃を防ぐ機器が、IPSやIDSです。IPSは不正侵入防止システム、IDSは不正侵入検知システムと呼ばれ、それぞれ外部からの不正侵入を防御・検知する機能があります。名前のとおり、IDSが不正なアクセスを検知して管理者に通知するだけなのに対し、IPSは不正なアクセスを検知すると、その通信を遮断するなど、侵入を防ぐ処理を行います(図2)。
図2:IPSでの通信の遮断(引用:増井敏克、おうちで学べるセキュリティのきほん、翔泳社、2015年、P.175)ここでいう不正侵入とは、DoS攻撃やSYN Flood攻撃など、目標のサーバに大量のパケットを送信し、サーバの正常な動作を妨害する攻撃を指します。このとき、通信内容を1つずつチェックしても、通信の宛先や発信元には問題がないため、ファイアウォールでは防げません。そして、その量が大量になった場合、……
>>第3回 第2章の続きを読む(PDFダウンロード)
WAFがWebアプリケーションを狙った攻撃を防ぐと考えると、他のアプリケーションを狙った攻撃も、防ぐ必要があるのではないでしょうか。実際、パソコンに導入されたアプリケーションを狙った攻撃は、多く発生しています。例えば、WordやExcelのようなOfficeソフトだけでなく、Adobe Acrobat ReaderやAdobe Flash Playerなどの脆弱(ぜいじゃく)性を狙った攻撃も多発しています。これらのアプリケーションの脆弱性を狙う場合、そこで使用されるファイルを悪用した攻撃が一般的です。攻撃の手段としては、マルウェアやウイルスが考えられます。Officeソフトのマクロを使った攻撃であれば、メールの添付ファイルなどを開くことでウイルスに感染させ、内部のファイルを破壊したり、個人情報を抜き出したりする事例が多く見つかっています。
ファイルを開いたときの動作やファイルに現れるパターンを見て、それがウイルスであると判定するのが、セキュリティ企業が提供するウイルス対策ソフトです。現在のパソコンでは、ウイルス対策ソフトを導入することが当たり前になっています。ただし、……
>>第3回 第3章の続きを読む(PDFダウンロード)
前回は、WAFとその他のセキュリティ技術との違いを説明しました。Webアプリケーションを狙った攻撃パターンは多岐にわたるため、その全てをWAFで検知することは決して容易ではありません。次々と登場する新たな攻撃に対応するには、検知するパターンのメンテナンスが必要になります。今回は、実際にWAFが行っている検知方法と、さまざまな運用や監視の手法、およびその最近のトレンドについて紹介します。
不正な入力をチェックしたいとき、まず思いつくのは、その入力に共通する要素を調べる方法でしょう。例えば、フォームにHTMLのタグが入力された場合に問題が発生するのであれば、HTMLのタグを入力できないようにすれば良いのです。このように、不正と判断される攻撃パターンのリストを用意しておき、その内容と一致する処理が行われた時にブロックする、もしくは無害化する方法を、ブラックリスト方式といいます。
身近でブラックリストという言葉を耳にするのは、クレジットカードを作成したり、ローンを組んだりする場面です。過去に延滞の発生や破産などによって信用が失われた場合、ブラックリストが発生します。そこに掲載されている人は、クレジットカードの作成やローンの申し込みができなくなります。
WAFでのブラックリストも同様で、……
>>第4回 第1章の続きを読む(PDFダウンロード)
ブラックリスト方式とは逆に、正常と判断される通信のみを許可する方法を、ホワイトリスト方式といいます。リストに登録されているもの以外は許可しないため、新たな攻撃パターンの発生にも影響を受けません。さらに、最初に適切なリストを作成しておけば、そのWebアプリケーションの仕様が変わらない限り、リストの更新作業は必要ありません。ただし、入力可能なパターンとして、文字の種類や文字数、入力形式など、全ての正常パターンを最初に登録する必要があるため、その作成には時間がかかります。実際には、ホワイトリスト作成機能を持つ製品があるため、一般的な通信を何度か繰り返すことで、そこに共通する内容を元に、WAFがリストを自動生成してくれます。こうした機能を使うことで、管理コストを削減できる可能性があります。
こうした簡便性から、ホワイトリスト方式の方がブラックリスト方式よりも人気を集めているようです。とはいえ、ホワイトリストとして定義できないような場面も存在するため、どちらが良いということはなく、アプリケーションの特徴に応じて使い分ける必要があります(表1)。
なお、Webアプリケーションの仕様変更や機能追加が発生した場合、……
>>第4回 第2章の続きを読む(PDFダウンロード)
ブラックリストとホワイトリストのどちらでも、許可と拒否、それぞれのリスト作成・更新を続けることが重要です。このためには、WebサーバとWebブラウザ間での通信や、Webアプリケーションでの処理内容に関する詳細な知識が必要とされます。こうしたリストの作成・更新を、社内で実施するのではなく、WAFベンダーが定期的に行う仕組みも登場しました。過去の攻撃パターンなどをデータベース化し、攻撃と判断できるパターンを抜き出す方法で、パターンマッチングといわれます。最近では、この判断を自動化するために、AI(人工知能)を活用するサービスも登場しています。正常な通信やログを確認・分析することで、不正アクセスのパターンや、防御するためのルールを自動的に更新する仕組みです。
これまでは、人間の手でブラックリストやホワイトリストを生成していました。これは非常に時間がかかり、誤りが発生することも少なくありませんでした。AIは、大量のログから正常時と攻撃時の特徴を学習できるため、人手で行っていた作業を代行できる可能性があります。人間のように疲れることなく、24時間365日体制での更新処理ができるため、専門的なスキルを持った人材が不足する、という問題の解消にもつながります。
上記のように、……
>>第4回 第3章の続きを読む(PDFダウンロード)
前回は、WAFの検知方法を説明しました。WAFの導入に当たって、具体的にどのような攻撃を防げるのか分からない、そもそも自社のシステムにWAFが必要なのか、という疑問を持つ人も多いのではないでしょうか。Webアプリケーションはさまざまな攻撃を受けます。今回は、特にWebアプリケーションに対してよく使われる攻撃方法と、WAFがどのようにしてこれを防ぐのかについて解説します。
ショッピングサイトやSNS、掲示板、検索エンジンなど多くのWebアプリケーションでは、データの保存にデータベースを使用します。こうしたWebアプリケーションでは、SQLという言語を使ってデータベース管理システムを操作します。プログラムの中でこのSQLの記述方法に問題があると、攻撃者が特殊な記述内容を送信してSQLに攻撃コードを埋め込むことで、開発者の想定していない指示を出すことができてしまいます。これにより、データベースの破壊や、個人情報の抜き出しなどが可能になります。
このように、不正な指示をSQLの中に注入する(インジェクション)ものが、SQLインジェクションという攻撃方法です。例えば、ログイン画面のあるWebアプリケーションがあります。入力したIDとパスワードが一致すればログインできる仕組みで、一般的な使い方であれば問題なく動作します。しかし、パスワードの欄に図1のような値を入力することで、IDさえ分かっていれば、パスワードを知らなくてもログインできてしまいます。
図1:SQLインジェクションの例(引用:増井敏克、おうちで学べるセキュリティのきほん、翔泳社、2015年、P.260)このとき、Webアプリケーションの中では、次のようなSQLが実行されていました。
ここに、上記のパスワードが入力されると、パスワード認証の部分が無視され、ログインできてしまったのです。これが、SQLインジェクションです。「’」のような記号が入力可能になっている場合、……
>>第5回 第1章の続きを読む(PDFダウンロード)
掲示板など、利用者投稿型のWebアプリケーションでは、利用者が入力した内容を他の人が閲覧できます。とても便利な仕組みである反面、利用者がHTMLの構文を含んだ内容を入力し、それをそのまま出力した場合は、問題が発生します。一般の利用者にとって、自由に好みのフォントや画像を投稿できるHTMLは便利なものです。しかし、攻撃者はスクリプトと呼ばれるプログラムを投稿できてしまいます。
攻撃者がスクリプトを投稿すると、利用者がその投稿を閲覧したときに、悪意のある処理が実行されます。例えば、そのウェブサイトにアクセスした利用者の情報を盗み出すことが可能になります。よく使われる例として、……
>>第5回 第2章の続きを読む(PDFダウンロード)
クロスサイトスクリプティングと似た言葉に、クロスサイトリクエストフォージェリがあります。これも複数のウェブサイトにまたがって発生する脆弱性ですが、入力内容を投稿するとき、適切なチェックが行われないことが原因となります(図3)。
図3:クロスサイトリクエストフォージェリ(引用:増井敏克、おうちで学べるセキュリティのきほん、翔泳社、2015年、P.266)例えば、……
>>第5回 第3章の続きを読む(PDFダウンロード)
前回は、WAFで守れる攻撃の例について説明しました。最終回となる今回は、実際にWAFを導入した後で、具体的にどのような運用や監視作業が発生するのか、その注意点を解説します。WAFは、導入すればそれで終わりではありません。攻撃手法は次々に変化するため、Webアプリケーションの仕様変更や機能追加も発生します。これらに合わせたチューニングが必要であり、サーバの負荷や出力されるログなども監視しなければなりません。
WAF の誤検知には、偽陽性と偽陰性があります。まず、この2つについて説明します。WAFを導入すると、攻撃を検知した場合に通信を遮断します。これが、実際の攻撃に対しての遮断であれば問題はありません。しかし、攻撃ではないのに遮断してしまう場合があります。つまり、一般の利用者が通常の使い方をしているにもかかわらず、誤検知が発生して遮断してしまうことがあるのです。これを、偽陽性(フォールス・ポジティブ)といいます。このような場合、利用者から問い合わせがあれば問題ありませんが、必ずしもそうとは限りません。重要な顧客が、この誤検知を不審に思わず、単にシステムが使えないという理由で離れてしまう可能性もあります。
逆に、攻撃者が攻撃を仕掛けたのに、WAFが問題のない通信と判断し、通過させてしまう場合もあります。これは、……
>>第6回 第1章の続きを読む(PDFダウンロード)
WAFを導入するときに忘れられがちなのが、運用にかかるコストです。一般的には、WAF製品の価格や動作検証にかかる人件費といった、導入時のコストに意識が向けられます。WAFの手法であるソフトウェア型、ネットワーク型、クラウド型など、その機能面に注目することもあるものの、いずれの場合でも、WAFを導入して終わりというわけではありません。
WAFの運用形態がブラックリスト方式かホワイトリスト方式かにかかわらず、そのリストのメンテナンスは必須です。新しい攻撃手法が登場した場合に限らず、Webアプリの仕様変更や機能追加などが発生するたびに、新たな見直しが必要になります。このとき、WAFの保守コストや運用コストを考える必要があるのです。特に、ログの確認やリストの更新といった運用にかかる人件費は、期間が長くなるほど大きくなります。
一般的には、……
>>第6回 第2章の続きを読む(PDFダウンロード)
ソフトウェア型のWAFをサーバに導入する場合、その分だけサーバの負荷は上昇します。スペックに十分な余裕があれば問題ないとしても、一時的にアクセスが急増した場合などには、サーバがダウンしたり、接続に長時間かかってしまったりする可能性があるため、その負荷をチェックする必要が出てきます。チェックの指標として、ウェブサイト利用者の視点でのレスポンスタイムだけでなく、ネットワークのスループット、サーバのリソース消費量が挙げられます。特に、サーバ内でのCPU使用率やメモリ使用量、ディスク容量のチェックなどはよく行われます。
多くの場合、……
>>第6回 第3章の続きを読む(PDFダウンロード)