フェイルセーフとは、
なぜフェイルセーフ機能が必要なのか?
Webシステムのセキュリティリスクを完全に排除することは不可能です。通常のPHPアプリケーション開発者は自分が書いたPHPスクリプトが安全であることに対して責任を持ちます。しかし、
例えば、
htmlspecialchars/
先ほどの例はPHP本体のセキュリティ上の問題でしたが、
Webアプリケーションにとって最悪の例を一つ紹介します。2007年1月にFlashPlayerの致命的なセキュリティホールを修正するセキュリティフィックスがリリースされました。古いFlashPlayerを利用しているユーザが悪意のあるページを参照すると、
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アプリケーションプログラマは、
スクリプトインジェクション/セッションハイジャックに備える
スクリプトインジェクションはWebアプリケーションに脆弱性がなければ攻撃されません。しかし、
無線LANと高速インターネット回線の普及により、
HTTPSプロトコルを利用した場合、
スクリプトインジェクションが可能な場合や盗聴によりセッションIDが盗まれた場合、
スクリプトインジェクション/セッションハイジャックに備える対策
- セッションクッキーを利用する
- セッションIDを頻繁に変更する
- セッション名にランダム文字列を使用する
- セッションIDが利用できる範囲を制限する
- 不正なセッションIDの利用がないか記録できるようにする
- 文字エンコーディングは必ずHTTPヘッダで指定する
- 入力文字列の文字エンコーディングを検証する
- エラーが発生した場合、
サニタイズせずプログラムの実行を停止する - 自動ログインを実装しない。実装する場合は正しく実装する
- 安易にウィジットを利用しない
- すべての入力値を可能な限り厳しい条件で検証する
- エスケープしてはならないデータ以外はすべてエスケープする
- データベースなど、
内部データを信用しない - データベースサーバなどが不正な文字データを保存できないようにする
- HTML、
CSS、 JavaScriptの生成はホワイトリスト方式を利用する - JavaScriptが無効なクライアントでも利用可能なサイトにする
- 関連するサイトが利用するドメイン名の一覧を提供する
- パスワードを正しく管理する
- ログイン処理を正しく実装する
- ユーザを教育する
これから一か月、
各項目の最後には