PHP4の最後のリリースとなるPHP 4.4.9が8月7日にリリースされました。筆者は「PHP4のメンテナンス状態はよくないので、可能な方は早くPHP5に移行すべき」と啓蒙してきました。しかし、大規模なシステムの場合、PHP4からPHP5への移行は簡単ではありません。筆者もgihyo.jpに比較的詳細な移行の注意点を解説させていただいています。
現在ではオンラインマニュアルの移行ガイドもかなり充実しています。
ビジネスユーザの場合、サービスを安定的に提供するために互換性のチェックやコードの修正が不可欠です。移行作業をしっかり行うにはかなりのコストが必要です。さらにPHP5はPHP4に比べバージョンアップが頻繁です。バージョンアップが頻繁であることはコストアップに直接つながります。このため、PHP4からPHP5に移行するためだけに予算を組むことは合理的な判断と言えませんでした。この結果、現在でもPHP4で運用しているビジネスユーザが多くいます。
PHP4をより安全に利用するTIPS
データベースクエリ用の文字列エスケープには専用関数を利用する
PHP4用のアプリケーションは古い物も多いので、データベースクエリ文字列のエスケープにaddslashes関数が利用されている物も少なくないと思います。addslashesによるエスケープでは文字エンコーディングベースのSQLインジェクションに脆弱になる場合があるので、pg_escape_string関数、mysql_real_escape_string関数を利用してエスケープしなければなりません。
MySQLを利用する場合、SET NAMESを利用しない
PHP4のMySQLはmysql_set_charset関数がバックポートされていません。このため、文字エンコーディングをSET NAMESで変更すると文字エンコーディングベースのSQLインジェクションが可能となる場合があります。SET NAMESを利用していても、文字エンコーディングが変更されていない場合は影響を受けません。
PostgreSQLを利用する場合、クライアント文字エンコーディングを変更しない
PHP4のPostgreSQLモジュールのpg_escape_string関数はデータベース接続引数が指定できません。利用するPostgreSQLのバージョンによっては文字エンコーディングベースのSQLインジェクションが可能になります。
入力文字のエンコーディングをmb_check_encoding関数で検証する
auto_include_file等を利用し、すべての入力文字列が正しい文字エンコーディングであることをチェックします。auto_include_file設定を利用すれば、PHPソースを変更しなくても文字エンコーディングを検証できるようになります。PHP 4.4.9以下, PHP 5.2.6以下のmb_check_encoding関数はヌル文字攻撃に脆弱なので文字列中に不正なヌル文字が含まれていないかもチェックします。
バンドル版のlibgdを利用しない
バンドル版のlibgdは脆弱性を含む古いコードが含まれています。PHPをソースからビルドしている場合、configureオプションで--with-gd=/usr等と利用するシステム上のlibgdライブラリを利用すれば、より安全にGDモジュールを利用できます。
セッション管理にクッキーのみを利用する
PHP4のsession.use_only_cookiesはデフォルトで無効に設定されています。セッション管理はクッキーのみを用いて行わないとなりません。
セッションモジュールにパッチを当てる
PHPのセッションモジュールはセッションアダプション（Session Adoption）と呼ばれる脆弱性があります。セッション管理にクッキーのみを利用していてもセッションアダプションの影響を受ける場合があります。
筆者のWikiにPHP5用のパッチ[1]とMasugataさんがポートされたPHP4用のパッチを掲載しています。
商用サポートを利用する
SRA OSS Incでは商用のPHP4延長サポートサービスを提供しています。
このサービスを利用するとPHP5で発見された新しい脆弱性がPHP4にも影響する場合、パッチ提供が受けられます。現在のところ、上記の脆弱性すべてに対応しています。PHP5ではサポートされているセキュリティ設定であるallow_url_include設定もサポートされています。
ビジネスユーザはPHP5に移行するならPHP6とも互換性が高いPHP 5.3がリリースされるまで待ちたい場合、商用サポートの利用を検討するのもよいでしょう。
