フェイルセーフとは，問題が発生しても致命的な被害が発生しないようにするか，被害を最小限に留める機能です。Webアプリケーションには様々なリスクが存在します。Webアプリケーションにはフェイルセーフ機能が必須と言えます。今回から連続してWebアプリケーションが備えているべきスクリプトインジェクション／セッションハイジャックに対するフェイルセーフ対策を紹介します。

なぜフェイルセーフ機能が必要なのか?

Webシステムのセキュリティリスクを完全に排除することは不可能です。通常のPHPアプリケーション開発者は自分が書いたPHPスクリプトが安全であることに対して責任を持ちます。しかし，PHPアプリケーション開発者が安全なコードを書くだけではシステム全体として安全性を維持することができないケースは少なくありません。

例えば，PHP5.2.5には非常に重要なセキュリティ上の修正が含まれています。PHP5.2.5より古いhtmlspecialchars／htmlentities関数は不正なUTF-8エンコーディングを利用するとhtmlspecialchars／htmlentities関数が正常に動作しないセキュリティホールがあります。

htmlspecialchars／htmlentities関数はセキュリティ維持のために必須の関数です。ユーザの入力をhtmlspecialchars／htmlentities関数でエスケープしてWebページに表示するだけの単純なWebアプリケーションでも，htmlspecialchars／htmlentities関数エスケープにだけ頼っていると不正なUTF-8エンコーディングによりスクリプトインジェクション攻撃を受ける可能性がありました。

先ほどの例はPHP本体のセキュリティ上の問題でしたが，Webシステムでは，もっと安全性維持が困難であるクライアント（ブラウザ側）のセキュリティ問題がWebアプリケーションの脅威となる場合が少なくありません。

Webアプリケーションにとって最悪の例を一つ紹介します。2007年1月にFlashPlayerの致命的なセキュリティホールを修正するセキュリティフィックスがリリースされました。古いFlashPlayerを利用しているユーザが悪意のあるページを参照すると，ブラウザに保存された任意のクッキーを盗める不具合がありました。Same Origine Policy（クッキーを参照できるのはクッキーを発行したドメインのみ）によって守られているはずのクッキーが守られていなかったのです。クッキーに保存されたセッションIDがほかのサイトから盗み取られると，セッションハイジャックにより簡単に別のユーザに成りすませます。

This update makes changes to the navigateToURL function to prevent potential Universal Cross-Site Scripting attacks. This issue is specific to the Flash Player ActiveX Control and the Internet Explorer Browser. (CVE-2007-6244)
http://www.adobe.com/support/security/bulletins/apsb07-20.html

※このセキュリティアドバイザリには、更に危険な、任意コード実行の可能性がある問題の修正も含まれています。

現実にはあり得ないことですが，仮にWebサイト側／クライアント側にインストールされたOS，Webサーバや言語（アプリケーション実行環境⁠）⁠，ブラウザやプラグインのセキュリティが完全であったとしても，Webアプリケーションの安全性を保証することは簡単ではありません。Webアプリケーションに発見される脆弱性は，OS，Webサーバ，アプリケーション実行環境やブラウザの脆弱性を大きく超える数の問題が見つかっています。

Webアプリケーションプログラマは，Webシステムが仕組み上非常に脆弱なシステムであることを正しく理解し，「⁠セキュリティ上の問題があることを前提」に構築しなけれならないことに留意しなければなりません。Webアプリケーションにはあらかじめ「セキュリティ上の問題があることを前提」とした「フェイルセーフ対策」が欠かせません。

スクリプトインジェクション／セッションハイジャックに備える

スクリプトインジェクションはWebアプリケーションに脆弱性がなければ攻撃されません。しかし，スクリプトインジェクションは最も頻繁にWebアプリケーションに発生する脆弱性です。スクリプトインジェクションはクッキーを盗むだけでなく，ページの改ざんや不正プログラムのインストールにも利用されます。HTTPSプロトコルを使っていないサイトの場合，盗聴によるセッションハイジャックの可能性を常に持っています。

無線LANと高速インターネット回線の普及により，自由に利用できる無線LANアクセスポイントも少なくありません。これらのアクセスポイントには暗号化がまったく行われていない場合さえあります。盗聴によるセッションハイジャックのリスクは以前より増していると考えられます。

HTTPSプロトコルを利用した場合，Webサーバへの負荷が増加したり，仮想ホストの設定の問題などがあるため，ログインが必要なサイトであってもHTTPSプロトコルを利用しないでサービスを提供しているサイトも少なくありません。

スクリプトインジェクションが可能な場合や盗聴によりセッションIDが盗まれた場合，フェイルセーフ機能により完全にリスクを無くすことはできません。しかし，フェイルセーフ機能を実装すると，リスクを最小限にとどめることができます。

スクリプトインジェクション／セッションハイジャックに備える対策

• セッションクッキーを利用する
• セッションIDを頻繁に変更する
• セッション名にランダム文字列を使用する
• セッションIDが利用できる範囲を制限する
• 不正なセッションIDの利用がないか記録できるようにする
• 文字エンコーディングは必ずHTTPヘッダで指定する
• 入力文字列の文字エンコーディングを検証する
• エラーが発生した場合，サニタイズせずプログラムの実行を停止する
• 自動ログインを実装しない。実装する場合は正しく実装する
• 安易にウィジットを利用しない
• すべての入力値を可能な限り厳しい条件で検証する
• エスケープしてはならないデータ以外はすべてエスケープする
• データベースなど，内部データを信用しない
• データベースサーバなどが不正な文字データを保存できないようにする
• HTML，CSS，JavaScriptの生成はホワイトリスト方式を利用する
• JavaScriptが無効なクライアントでも利用可能なサイトにする
• 関連するサイトが利用するドメイン名の一覧を提供する
• パスワードを正しく管理する
• ログイン処理を正しく実装する
• ユーザを教育する

これから一か月，補講として集中してこれらの対策を解説します。

各項目の最後には「対策のまとめ」を記述しています。できるだけ漏れがないよう網羅的に対策のポイントを紹介しています。このため，各項目で重複した対策が記載されていたり，解説されていない対策が記載されている場合もあります。解説されていない対策は後にこのシリーズのいずれかの項目で解説されます。

解説する順番と対策の重要性に関連性はありません。重要性よりもありがちな間違い，設定ミスなどを最初のほうに解説しています。