 |
 |
|
|
| 最新ニュース |
|
|
|
|
|
|
||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
|
Webアプリの脆弱性は5＋1の分類で把握せよ－NTTデータCCS長谷川氏 |
||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
|
開発工程でのWebアプリセキュリティのススメ
|
||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
なぜ、Webアプリケーションの脆弱性はこうも甚大な被害を生み出すのか。WAS事業を展開している住商情報システム（以下、SCS）主催のWebアプリケーション開発者向けセミナーに登壇した、NTTデータCCS アウトソーシング事業本部 ネットワークサービス部 シニアセキュリティスペシャリストの長谷川武氏は、次のように説明する。同氏は脆弱性検査の豊富な経験を持ち、IPAで非常勤研究員としても活躍するWASの第一人者だ（なお、細かい表現は筆者が再構成している）。 「まず、Webアプリケーションの開発は比較的容易なため、開発者が未熟なケースがある。その反面、異なる複数の技術を組み合わせなければならないので脆弱性が生まれやすい」。例えばパッケージ製品であれば、ある程度整った体制にて開発され、定期的にバージョンアップなども行われるため、そのタイミングで脆弱性が修正されることが多い。一方、企業ごとに個別開発されるWebアプリケーションは定期的なパッチが配信されることもなく、脆弱性が気づかれずに放置される可能性が高いのである。 同氏はさらに「ネットワークを通じて全世界に公開されたWebサイトは攻撃者にとっても狙いやすいもの。一般にも広く利用されているため、セキュリティ事件が起きたときの社会的影響が大きい」と述べる。 IPAへの脆弱性関連情報の届け出件数を見ると、特に多いのはクロスサイトスクリプティング（XSS）脆弱性とSQLインジェクション脆弱性だが、Webアプリケーションの脆弱性はこれだけではなく、開発者としては、この2つ以外にも対策方法を知っておかなければならないという。 とはいえ、非常に種類が多く細分化された脆弱性を総合的に学ぶには、あちこちから断片的に情報を集めてこなければならず、大変というのが開発者の本音ではないだろうか。 そこで同氏が提唱するのが、侵害パターンによる「5＋1の類型」だ。Webアプリケーションの侵害パターンは、その脆弱性の性質によって異なる。同氏はそのパターンから脆弱性を「暴露問題」「エコーバック問題」「入力問題」「セッション問題」「アクセス制御問題」の5種類と、それらどれにも含めることのできない「各種の問題」に分類し、「こうすることで脆弱性を体系的に把握することが可能になり、対策の検討もしやすくなる」としているのだ。 ■ 運用上の不備による「暴露問題」 暴露問題とは、顧客リストなどの秘密情報が、Webサーバーの基本的振る舞いによって漏えいしてしまうもの。Webアプリケーションの脆弱性が広く認知される前は、公開フォルダに格納された顧客リストが、Webブラウザからファイル名を予測してアクセスするだけで、外部から閲覧できてしまった事例がある。また、URIに「../../../etc/passwd」といった不正なパラメータを挿入し、想定外のパスへアクセスする「ディレクトリトラバーサル攻撃」もこの範ちゅうだ。長谷川氏は「これは最も単純な脆弱性。システム自体の欠陥というよりも、保守の際に一時的に別の場所へ移動させたファイルを作業終了後に消し忘れる、などの運用上の不備によるところが大きい」と指摘。予防的実装例としては、重要なファイルやソースファイルは十分に隠し、「../」などを含むパスや絶対パス名を拒否すること。また、そもそも重要な値をパラメータで受け渡さないといったことや、セッション変数を積極的に使用し、キャッシュを残留させないことも有効としている。
■ 入力値をそのまま出力してしまう「エコーバック問題」 エコーバック問題は、Webアプリケーションが入力パラメータの値をそのまま出力してしまうことで、Webブラウザやキャッシュ設備などにセキュリティ侵害が生じるもの。XSSが代表例だ。そのほか、CR/LFでHTTPヘッダを不正に改ざんしてレスポンスを分割する「HTTPレスポンス分割攻撃」もここに含まれる。XSSの予防的実装例としては、「HTMLコンテンツに入力値をそのまま出力しない」「出力される特殊記号を加工あるいは抑制する」ことが有効。加えて「比較的安全なタグ属性」「タグのURL属性」「タグのstyle属性、イベントハンドラ属性、scriptタグの内側」の3種類の文脈に応じた対策を心がけるようにとしている。「特に後者の2種類が危険なタグ。最近は、Ajaxでscriptタグの内側にIDを埋め込むこともあるが、これは聞いただけで緊張感の増す実装なのである」（同氏）。
■ 悪意のパターンが注入されてしまう「入力問題」 3つ目が、入力パラメータに悪意のパターンを仕組んでサーバーに注入・侵害する「入力問題」。SQLインジェクションはここに分類され、ほかにもコマンド/LDAP/XPATH/SSIインジェクションなどが含まれる。この問題の原因は、Webアプリケーション側で悪意の入力を排除できていないことだ。予防的実装例としては、特殊な文字列を制限することが重要で、SQLインジェクションならば、「'（シングルクォート）」「\（バックスラッシュ）」「;（セミコロン）」などのエスケープが必須だが、加えてシングルクォートの内側と外側など文脈に応じた対策を行うほか、プリペアド・ステートメントを使用するのもよいという。 その上で「入力検査の徹底も有効。例えば入力フォームの文字種、けた数、値の範囲を厳密に検査しなくてはならない。また、ユーザーが文字を直接入力するテキストボックスのような項目も、文字を直接入力しないラジオボタンも、HTTP上では同じようにパラメータを送信する動作となるので、直接入力するか否かに関係なくすべての項目を検査するように」（同氏）としている。
■ 「セッション問題」「アクセス制御問題」および「各種の問題」
Webサイトでは継続的なサービスを提供するために、ユーザーごとに特有のセッションIDを生成して、どの通信がどのユーザーのものかを追跡している。セッションハイジャックの手口は、このセッションIDを予測したり、何らかの方法で盗み出してしまうものだ。例えば、単純にCookieにセッションIDを格納するだけの実装では、盗むのもたやすい。また、わざわざ盗むまでもなく、攻撃者が用意したセッションIDを正規ユーザーに意図せず利用させる「セッションフィクセーション（セッションIDのお膳立て）」という手口もある。もしもセッションIDの値が固定だとすると、正規ユーザーがWebサイトにログインしたあとに、攻撃者も同じセッションIDを使って簡単に正規ユーザーになりすますことができてしまう。 5つ目の「アクセス制御問題」は、ユーザー認証とアクセス承認の仕組みが不十分であるがために発生するものだ。本来、認証が通らなければアクセスできない保護されたデータに、認証なしでアクセスできてしまうのが具体的な侵害内容で、過去には、どこからか知り得たログイン後のURLをアドレスバーからたたくだけで、会員専用ページにアクセスできてしまった事例もある。 そして以上5種類に分類できない、メールの第三者中継、リダイレクタを用いた詐欺、フィッシング詐欺サイトなどが「各種の問題」に含まれる。 「セッション問題、アクセス制御問題、および各種の問題はほか3つよりも複雑な侵害パターンで、「そのためある程度上流の設計段階から対策が必要となるケースがある」と同氏は指摘する。 ■ 開発工程でのWebアプリセキュリティのススメ
「開発工程には、要件定義から基本設計・機構設計、詳細設計・単体テスト、システム統合・組み合わせテストなどのフェーズが存在する。脆弱性は上流の要件定義から種がまかれ、フェーズごとに成長していくもの。出荷前の段階では大量の脆弱性が発生しており、ここで検査を行ってもコスト的に、優先度の高いものだけをつぶすにとどまる可能性があるのだ。なので今後は出荷前検査だけでなく、開発工程の要所要所で開発者自身が検査してコード修正するほか、要件定義の段階からも、必要なことが抜けていないかなどセキュリティに配慮していくのが望ましい。もちろん、それでも完全に脆弱性をつぶすのは至難の業だが、出荷前検査だけよりも、リスクを大きく減らし、かつコストも抑えることができる」（同氏）。 また実装においては、「先に紹介したような予防的実装のほか、フレームワークを利用するのも有効。用意されたスタイルに沿って開発することで、品質のムラや機能漏れを防ぎ、プログラマは個々のアプリケーションの仕様に専念できるはず。フレームワークにも脆弱性対策が十分に備わっているとは限らないが、フレームワークレベルで対策を施せれば、個々のプログラムに対策を記述せずに済む」（同氏）とのこと。 一方、脆弱性検査も「もはや不可欠な存在」として推奨する。検査方法には、自動検査ツールを用いたブラックボックス検査、手動によるブラックボックス検査、ソースコード検査などバリエーションがあるが、「検査ツールは手間が少なく網羅的に検査が行える。反面、主にセッション問題やアクセス制御問題の検出は苦手な面もある（最近は機能的に克服されつつもあるが）。これに比べて手動検査は人間の価値判断でより深い検査が行えるが、そもそもブラックボックス検査自体にどうしても限界がある。一方、ソースコード検査は脆弱性のあるロジック部分を明確に見つけることができるが、多くの時間がかかるのがデメリット。どれにも一長一短があるので、バランスよく組み合わせるのが理想だ」（同氏）とした。 なおSCSは、Webアプリケーションの脆弱性検査ツール市場で2強の位置にある「IBM Rational AppScan」「HP WebInspect」の両製品を取り扱っている。SQLインジェクションなどで被害を出さないために最も重要なのは、長谷川氏の言葉どおり「開発段階での予防的実装」であるが、すでに運用がスタートしているシステムにおいては、こうした検査ツールによって脆弱性を洗い出すことが最も現実的な解となる。セキュリティに不安のあるWebサイトの管理者や運営者は、検査ツールの購入や検査サービスの利用を検討してみてはどうか。2008年のSQLインジェクション事件の数や影響を考えると、WASの実践はもはや社会的な義務ともいえる。 ■ ＵＲＬ 住商情報システム株式会社 http://www.scs.co.jp/ 株式会社NTTデータCCS http://www.nttdata-ccs.co.jp/ IPA「セキュア・プログラミング講座」 http://www.ipa.go.jp/security/awareness/vendor/programmingv2/ ■ 関連記事 ・ CookieにSQLインジェクションを埋め込む新手の手口、ラックが緊急注意喚起（2008/10/03） ・ SQLインジェクションとXSSの失敗例を示した「安全なウェブサイトの作り方 改訂第3版」（2008/03/06） ・ 米IBM、Webアプリ脆弱性検査ツール「IBM Rational AppScan」（2007/11/16） ・ MBSD、ASP型の脆弱性検査サービスを提供－ユーザー自身がいつでもチェック可能（2007/03/12）
（ 川島 弘之 ）
|
