三井物産セキュアディレクション株式会社
　　　　　サービスオペレーションセンター　セキュリティ検査グループ 　　コンサルタント　中村　隆之

■Web サイトへの攻撃とその被害

　昨今、個人情報漏洩事件が相次いでいるが、Web サイトへの攻撃による被害は個人情報漏洩だけではない。サービスの不正利用、妨害、破壊、他サイトへの攻撃の踏み台など様々である。個人情報も重要であるが、それ以外の被害についても留意する必要がある。Webサイトへの攻撃方法は以下のように分類できる。

（1）OS、Webサーバ等の既知の脆弱性を利用するもの

（2）OS、Webサーバ等の設定ミスを利用するもの

（3）Webアプリケーションの脆弱性を利用するもの

　（1）は、Web アプリケーションよりも下のレイヤに位置するWebサーバやDBサーバ、OS などの脆弱性を利用するものである。これらは「既知」であるので、通常はベンダーから修正パッチが公開されている。このパッチを当てていれば攻撃を受けることはないのだが、運用がいい加減であったりすると、この攻撃を受けてしまう。既知の脆弱性を利用するには攻撃用のプログラムが必要となるが、通常は見付かった脆弱性と一緒に再現プログラムも公開されているため、技術力がそれほど高くなくても攻撃を行うことができる。ワームによる攻撃も基本的に既知の脆弱性を利用するものだ。
　既知の脆弱性を利用する攻撃はバッファオーバーフロー系が多く、Web ページの改竄、サーバの乗っ取り、踏み台としての利用、といった被害を想像されるかもしれないが、Webに関係するところだと、ソースコードの漏洩、任意のファイルの漏洩、セッション管理の不備による他人へのなりすまし、などがある。Web サイト上で個人情報やその他の機密情報を扱っている場合には、この脆弱性によってそれらのデータが漏洩してしまうため、非常に深刻な被害を受けることになる。
　（2）は、Web サーバ、Web アプリケーションサーバ、OS、DBサーバ等の設定ミスを利用する攻撃である。色々な設定項目があり、設定ミスも色々あるが、簡単なものとしては、

・アプリケーションとして動作せずにファイルの中身をそのまま表示してしまった

・URLでディレクトリを指定したら、ファイル一覧が表示されてしまった

・Webサーバを最新版に入れ替えたら、設定ファイルが上書きされていてクライアント証明書による認証が効かなくなってしまった

　といったものがある。発見される頻度としてはそれほど高くはない。発見された場合に想定される被害は設定項目に依存するが、例えばファイル一覧が表示されてしまう脆弱性では、ディレクトリ内に個人情報を書き込んだファイルを置いている場合、その個人情報が外部から閲覧可能となる。
　（3）は、Webアプリケーションの作り方の問題であるため、（1）と（2）と違い、インフラのセキュリティ対策だけでは防げない攻撃である。Webアプリケーションの脆弱性は表1のように分類できる。筆者がこれまでに行ってきた検査では、表１で示した脆弱性のほとんどが、どこかのサイトで検出されている。
　本稿では個々の脆弱性についての説明は行わないので、詳細については、以下のURLを参考にして頂きたい。なお、脆弱性の分類方法がサイトごとに異なるため、多少分かりにくい部分があるかもしれないが、どこのサイトでも言っている内容は同じである。

◆OWASP（The Open Web Application Security Project）
　　http://www.owasp.org/index.jsp

◆WASC（Web Application Security Consortium）
　　http://www.webappsec.org/


　　　　　　　　　　　　表1 Web アプリケーションの脆弱性の分類

■脆弱性の原因と対策

　Web アプリケーションが脆弱となる原因は沢山あるが、その中で重要と思われるものを以下に示す。

（1） Web アプリケーションのセキュリティに関する意識が低い

（2）要求仕様にWeb アプリケーションのセキュリティに関する項目がない

　まず（1）だが、従来のクライアント／サーバアプリケーション（以下、C/S アプリケーションと記す）と同じようにWeb アプリケーションを開発しようとしてしまっているのではないかと筆者は思う。従来のC/Sアプリケーションとは、ローカルネットワーク上で、独自開発のクライアントアプリケーションを使ってサーバとやりとりするものを想定している。Web アプリケーションとの決定的な違いを以下で説明する。

・独自プロトコルとHTTP：従来のC/Sアプリケーションでは、サーバとの通信に独自プロトコルを使うことが多い。独自プロトコルの場合は、プロトコルを解析する手間がかかるため、リクエストを改竄して送信することが多少難しくなる。クライアントとサーバ間で暗号化されてしまうと、リバースエンジニアリングでもしない限り、リクエスト改竄はほぼ不可能である。

　一方、Web アプリケーションが通信で使うHTTP プロトコルは仕様が公開されているため、解析の必要がない。また、HTTPリクエストを書き換えるツールも存在し、これを使うとCookieやhiddenパラメータなどブラウザが送信する全てのデータを簡単に書き換えることができる。SSL で通信が暗号化されている場合も例外ではなく、このツールによって書き換えが可能である。簡単に書き換えができてしまうということは、書き換えられては困るパラメータをリクエスト内に含めてはならないということである。

・独自アプリケーションとWeb ブラウザ：従来のC/S アプリケーションでは、クライアントとしてWeb ブラウザでなく独自のアプリケーションを使う。独自アプリケーションの場合、画面の枠組や画面遷移、アプリケーションのステータスはクライアント側で管理していることが多いと思う。
　必要なデータのみをサーバから取ってきて表示する仕組みでは、リクエスト改竄によって全く異なる動作をさせることは難しい。しかしWeb アプリケーションの場合、表示される画面データは全てサーバから返されるので、リクエスト改竄により、まったく異なる画面に遷移することも可能である。そのため、Web アプリケーションでも同じようにクライアント側で画面遷移やステータスの制御を行おうとすると、CookieやURL パラメータ、hiddenパラメータの改竄により、他人へのなりすましのような深刻な脆弱性が発生することになる。

　次に（2）であるが、これは開発者だけでなく、発注者側も注意しなければならないことである。正しい動作やカットオーバーが重要であることは当然なのだが、要求仕様にWebアプリケーションのセキュリティに関する項目を入れておくと、安全性が「仕様」となるため、開発者側もWebアプリケーションのセキュリティについてもっと注意を払うようになるのではないかと思う。
　ただ、要求仕様にセキュリティの項目があったとしても、正しい対策を取れるかどうかは別であるので、発注者側の場合は、開発会社を選定する基準を設けたり、開発会社側の場合は、もっとWeb アプリケーションのセキュリティについて調査したり、セキュリティのトレーニングを受講したりするとよいだろう。


　　　　　　　　　　図1 ログイン処理におけるリクエストの流れ

■Web アプリケーション検査の種類と特徴

　Webアプリケーションの検査はツールによる検査と手動による検査の2通りに分けることができる。それぞれの違いについて説明する前に、まずは検査全体の流れを簡単に説明しておこう。

■Webアプリケーション検査の流れ

　ここで説明する手順は大まかな流れであり、実際にはもっと細かい作業が多く存在するが、本稿では重要と思われる作業のみを説明することにする。

・サイト巡回：検査対象となる画面を全て洗い出すために、可能な遷移先を順に辿っていく作業である。ここで、検査対象の「画面」と言っているが、実際の検査対象は画面ではなくHTTPリクエストである。図1のログイン処理を例にあげて説明する。ログイン画面でID とパスワードを入力して送信すると、次に表示される画面はログイン後のメニュー画面となる。この例で検査対象となるのは、赤の矢印で示したリクエストである。Login.cgi でID とパスワードを送信したあと、Login2.cgiにリダイレクトしている。この部分は通常のブラウザでは見えないが、Web アプリケーション検査を行う際は、この「見えないリクエスト」についてもきちんとカウントし、検査対象に入れる必要がある。

・テクニカル検査：検査対象の各画面において不正な文字列を入力し、それに対して正しく処理できているかどうかを確認する作業である。アプリケーションが不正入力を正しく処理できていない場合は、OS コマンドが動作したり、任意のSQL 文を実行できたり、任意のファイルを表示できたりする。アプリケーションに脆弱性が存在したとしても、ここで入力する「不正文字列」が攻撃として成功するためには、その脆弱性に合った文字列である必要がある。つまり、脆弱性を検出するためには、不正文字列を何パターンも試さなければならない。

・ロジック検査：ロジック検査とは、アプリケーションに渡すデータを、アプリケーション的には正しいフォーマット内で改竄する攻撃である。例えば、価格改竄によりショッピングサイトで商品を安く購入したり、セッションIDの書き換えにより他人になりすましを行ったりする攻撃がある。ロジック系の脆弱性は、サービスを悪用されることが被害であるため、発生する被害はサービスの重用度に依存する。ここでいう「サービス」は、サイト全体（例えば、オンラインバンキング）と、個々のアプリケーション（例えば、ユーザー情報の表示機能）の両方を意味している。

・報告書作成：テクニカル検査、ロジック検査の結果をまとめる作業である。アプリケーションの修正方法についても記載することもある。これについては、特別詳しく説明する必要はないだろう。

■ツールによる検査

　Web アプリケーション検査用のツールは商用のものが数種類存在する。ここでいうツールとは、Web アプリケーションをほぼ自動的に検査してくれるツールのことを指している。本稿では個々の製品についての詳しい説明は行わず、一般的な機能と利用する場合の注意点について説明することにする。ツールが持つ基本的な機能は以下の通りである。

・自動巡回：自動的にリンクを辿っていく。ID／PWや住所などの情報を予め与えておくことで、その情報を使用できるフォームではツールが自動的に値を入力して送信し、フォームを埋められない場合はユーザー側に通知して手動でフォームを送信してもらい、そこから先を再びツールが巡回する。

・自動検査：自動巡回で記録した検査対象リクエストをもとに、自動的にパラメータを書き換えて送信し、攻撃が成功したかどうかをレスポンスから判断する。検出した結果は、誤検知がないかどうか人間が一度チェックし、誤検知の場合はそれを取り除く。

・報告書作成：検出された脆弱性の説明と対策を出力する。このように、ツールを使うと一通りのことはやってくれる。但し、利用の際は以下の点について注意する必要がある。

・自動巡回漏れの可能性： Web アプリケーション全体の画面遷移図や、検査対象アプリケーション一覧がある場合は問題ないが、そうでない場合は巡回漏れの可能性も考えられる。巡回漏れが考えられるのは、何らかの条件によって画面遷移が変化するアプリケーションの場合である。このような作りのアプリケーションは、人間の判断なしでは全ての画面を辿ることは難しいだろう。

・検査時の前提条件と後処理：商品を購入するアプリケーションの場合、（1）商品をカートに入れる、（2）レジに進む、（3）確認する、（4）確定する、といった画面遷移になるだろう。ここで、（4）の「確定する」というリクエストの検査を行う場合、（1）〜（3）が既に行われた後のステータスにしてからリクエストを送らなければならない。筆者はこれを前提条件と呼んでいる。ツールで検査する場合、前提条件はセットしてくれない。あるリクエストを実行するために、どのような条件が必要かは人間の判断が必要だろう。そのため、厳密に画面遷移やステータスをチェックしているアプリケーションの場合、自動検査ツールでは正しく検査できないこともありうる。
　後処理とは、前提条件と似たようなもので、検査対象リクエストを送信したあとに実行し、再び検査対象リクエストを送信できるステータスに戻す処理を行う。後処理についても人間の判断が必要であり、ツールではサポートされていない。

●手動による検査

　手動で行う場合、ツール利用時の問題点はほぼ解消される。但し、手動の場合はツールの長所がそのまま問題点となる。例えば以下に示すようなことである。

−検査に時間がかかる

−検査担当者によって検出能力に差が出る可能性がある

−報告書の作成に時間がかかる

−作業日数がかかるので費用がかかる

　そこで考えられるのが、検査支援ツールである。これは、手動による検査において、自動化できる部分を自動化して全てツールに行わせるようにしたものである。
　これを使うことで、検査にかかる時間が減り、かつ、検査の質もより一層向上することになる。商用製品やオープンソースではこのようなツールは見当たらないが、いずれは出現するのではないかと思う。