なぜPHPアプリにセキュリティホールが多いのか?
第12回 フェイルセーフ ── 万が一に備える
フェイルセーフとは,
なぜフェイルセーフ機能が必要なのか?
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が無効なクライアントでも利用可能なサイトにする
- 関連するサイトが利用するドメイン名の一覧を提供する
- パスワードを正しく管理する
- ログイン処理を正しく実装する
- ユーザを教育する
これから一か月,
各項目の最後には
この記事に関連する書籍
-
Webアプリセキュリティ対策入門〜あなたのサイトは大丈夫?
本書は,Webサイトのセキュリティ確保のために必要な基礎知識と,安全なコードを書くために必要な基礎知識を解説しています。Webアプリケーションは比較的簡単に作成で...
-
はじめてのPHP言語プログラミング入門
Webアプリケーション構築ツールとしてPHPを取り上げた書籍は数多くありますが,言語の解説・入門書としての書籍はあまりありません。 本書は,プログラミング言語として...
バックナンバー
なぜPHPアプリにセキュリティホールが多いのか?
- 第46回 セキュリティ対策を考える上で欠かせないコンテクスト
- 第45回 入力バリデーションはセキュリティ対策
- 第44回 セキュリティ対策が確実に実施されない2つの理由
- 第43回 PHP 5.3のcrypt関数の問題
- 第42回 PostgreSQL 9.0に見るSQLインジェクション対策
- 第41回 PHP 5.3.4におけるセキュリティ上重要な仕様変更
- 第40回 MOPS:安全性の高いパスワードハッシュ作成ツール - phpass
- 第39回 MOPS:静的PHPソースコード脆弱性スキャナ RIPS
- 第38回 MOPS:PHPにおけるコード実行(2)
- 第37回 MOPS:PHPにおけるコード実行(1)