カテゴリー: Development

PHP 5.2.4

ご存知の方も多いと思いますがPHP 5.2.4のリリースが近いです。しばらく前にRC1が出ています。

http://qa.php.net/

どのWebアプリケーションもですがインフラとなるソフトウェアのバージョンアップをどう行うか定めておかなければなりません。オープンソースの場合、いつでもソースコードのリポジトリから開発版が利用できるので開発版を利用してアプリケーションの動作に支障が無いかテストできます。

しかし、普通は開発版で常に動作テストは行えません。次のバージョンがリリースされる前にしばらくの間RC版(Release Candidate版)がテスト用に配布されます。RC版の間であればクラッシュバグや意図的でない動作仕様の違いなどをバグレポートとして提出すればリリース前に修正される可能性が高くなります。パッチを付けて送付すれば適用される可能性も高くなります。RCで動作テストを十分行っていればリリースされた場合にセキュリティフィックスが含まれいても慌てることはありません。

大規模にシステムを運用している会社であればRC版からの動作テストのメリットは非常に多いです。RC版からの動作テスト&フィードバックを強くお勧めします。

HTTP_ACCEPT_CHARSET/HTTP_ACCEPT_LANGUAGEの取り扱いバグ

b2evolutionをいい加減アップグレードしておかないと問題があっても困るのでアップグレードしました。HTTP_ACCEPT_CHARET/HTTP_ACCEPT_LANGUAGE処理の不具合がまだなおっていないようです… 日本語のように単語区切りがない言語(または正規表現の文字エンコーディング設定)の不具合も直っていないようです。

昨日から今日までMac版のFirefoxなら正常に表示、Win版だとISO-8859-1になって文字化けしていました。(多分IEも同様だったはず)

文字列の比較はできるかぎり厳密に行う方が良いですがHTTP_ACCEPT_CHARSET/HTTP_ACCEPT_LANGUAGEの比較では大文字/小文字を無視した方が無難だと思います。Win版Firefoxがへんな値に設定しているとは思いますが、統計アプリなどでみるとかなり変わったエンコーディング名になっている場合もあるようです。

エンコーディングをUTF-8で統一しているなら

conf/_locales.phpを以下に設定し

$evo_charset=’utf-8′;
$force_io_charset_if_accepted=’utf-8′;
$db_config[‘connection_charset’]=’utf-8′;
$default_locale=’ja-JP’;

必要ないような気もしますがこのファイルに定義してあるlocaleでiso-8859-1エンコーディングは全てutf-8に変更しました。

inc/MODEL/settings/_locale.funcs.phpのinit_charset関数でなにもせずにreturn

function init_charset( $req_io_charset )
{
return;

すれば文字化けは解消します。

追記:
これでもISO-8859-1になって文字化けするケースがありますね… 時間がないので場当たり対処策としてindex.phpの最後に

header(‘text/html; charset=UTF-8′);

を追加しました。ロケールの処理にはいろいろ問題があるようです。どこかで無理矢理ISO-8859-1にするくらいならデフォルトUTF-8にしておけば良いと思います。

さらに追記:
上記の変更を行うとRSSフィードのXMLエンコーディングの部分が空になり、XMLエラーとなってRSSリーダが処理できない不具合が発生する事が分かりました。ソースを見れば一目瞭然で文字エンコーディングを指定する変数が空であることが原因でした。

conf/_basic_conf.phpに

$io_charset=’utf-8’;

を追加すると直ります。アップグレードマニュアルにはこのファイルは前のファイルで上書きするように、と書いてあったのですが追加設定が必要だったのかも。

PHP4からPHP5への移行について

PHP4のサポート終了がアナウンスされことに伴い、技術評論社の方からPHP4からPHP5への移行の記事を書く事になりました。毎週新しい記事が公開されます。下記のURLが最初の記事で8/2(予定)から順次続きが公開されます。

http://gihyo.jp/dev/feature/01/php-migration/0001?page=1

記事を書いてみて思ったのですが、自分にとってはPHP4とPHP5両方で動作するコードを書くのはそう難しくないのですが時々PHPでコードを書いている方、PHPの開発状態を把握していない方には結構難しいのではないかと思いました。今回の記事は「移行」にのみ焦点をあててPHP5の新機能はほとんど紹介しませんでしたがかなりボリュームになってしまいました。それでも十分とは言えないです。PHP5への移行をお考えのかたは8/2から上記URLを参考にして頂ければ幸いです。

ところで、隔週(の予定…で実際は月一回くらい…)でセキュリティ関係の記事も http://gihyo.jp/ にて連載しています。こちらもよろしくお願いします。

http://gihyo.jp/serial/2007/php-security

どの記事でもコメントなどございましたらメールで頂けると助かります。

PHPでQtアプリ

PHPでGTKアプリが作れるPHP-GTKは以前からありましたが、PHPでQtアプリが作れるPHP-Qt 0.1がリリースされています。

The PHP-Qt team is pleased to announce the immediate release of PHP-Qt Version 0.1!
It’s been nearly a year since the release of version 0.0.3 and many, many things have changed, including the move to using the Smoke library.
A few of the changes from 0.0.3 to 0.1 are:

* Unit tests based on phpunit
* Overriding of Qt methods in PHP classes
* Improved startup time
* Improved runtime speed
* improved inheritance
* CMake-based build system
* Support for references
* There is now a global tr() function
* Based on the Smoke library
* License: GPL (see note below)

PHP4のサポート終了は2008/8/8

現状でもセキュリティフィックスの状態があまり良いとはいえないのでPHP5が利用できる場合は積極的にPHP5を利用すべきですが、2007/12/31まで通常メンテナンス、以後2008/8/8までセキュリティフィックスには対応ということです。

まだの方は早くPHP5に移行しましょう。

間違っても5.1系に移行しないようにしましょう… 5.1系は今現在もメンテナンスされていません… 5.2系のみメンテナンスされています。

tidy_parse_string() オーバーフロー

CVE-2007-3294にtidy_parse_string()オーバーフローが登録されています。

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-3294

に脆弱性情報のソースURLが記載されています。

http://www.milw0rm.com/exploits/4080

すぐに応用可能な実証コード付きです。Linuxだと影響が大きすぎると考えたのか、実証コードの作成者がWindows環境が得意なのか、Windows環境のコードになっています。

tidy_parse_string()の第二引数(動作設定用パラメータ)のオーバーフローを利用しているので専用サーバで運用しているユーザにはあまり重要な脆弱性ではありません。(普通のコードならローカルからしか攻撃できない)しかし、PHPの場合、共有ホスティング環境で運用すできでないアプリケーション(たとえばECアプリ)も多く利用されているので「Base score: 7.5 (High) 」とレーティングされても仕方ないところでしょう。

PHPセッションの問題修正

Stefanさんのブログに書いてあったので気がついたのですが

http://cvs.php.net/viewvc.cgi/php-src/ext/session/session.c?r1=1.417.2.8.2.35&r2=1.417.2.8.2.36

に結構面白いコミットがされています。CVS版なので正式リリースになるかは不明です。成り行きはがどうなるかは興味深いです。

MOPBで解説されていたセッションIDにインジェクションができる問題を修正しようとブラックリスティングで対応させようとしたようです。ブラックリスティングより暗号化した方が安全性と互換性を確保するのが簡単なのですがZend社の社員によるコミットだったのですがZend Platformとの互換性も維持できないパッチになっているようです。Stefanさんのブログを見るとかなり皮肉な書き方であることが分かります。このような文面になった背景にはZend社の社員により「PHP開発者に知らせず脆弱性を公開した」とあらぬ言いがかりを付けられためだと思います。

非常に古いPHPの場合、セッションIDには好みの文字列が設定できたのですが最近のPHPは

\r\n\t <>’\”\\

が不正な文字として登録されています。\r\nはヘッダスプリティング、<>'”\はXSSに明らかに利用できるので不正としても仕方ない文字ですが、

()@,;:[]?={}&%

も新たに不正な文字に加えられたました。:はZend Platformでも使っている文字だそうです。
備考: セッションIDに管理用の文字列を付け加えるのは珍しいことではありません。負荷分散や分散されたサーバ間でのデータ共有など様々な用途に管理用の文字列を付け加える場合があります。

暗号化による対処の方がシンプルかつ安全な対策だと思います…

ところで、単純にクッキーだけでセッションIDを使っている場合には問題は発生しません。つまりsession.use_trans_sid=0, session.use_only_cookies=1でPHPを使っていれば現在のPHPを使っていてもここで問題としている不具合には影響されません。

PHP 5.2.3リリース

日本語環境でMySQLを利用している方には、リリースノートに記載されているmysql_set_charset()の追加に重要な意味がある方も多いと思います。

Added mysql_set_charset() to allow runtime altering of connection encoding.

PHP4にはまだ追加されていませんがかなり重要なセキュリティフィックスだと思います。mysql_set_charset()はlibmysqlのmysql_set_character_set()の簡単なラッパー関数です。

http://dev.mysql.com/doc/refman/4.1/en/mysql-real-escape-string.html

“If you need to change the character set of the connection, you should use the mysql_set_character_set() function rather than executing a SET NAMES (or SET CHARACTER SET) statement. mysql_set_character_set() works like SET NAMES but also affects the character set used by mysql_real_escape_string(), which SET NAMES does not”

つまりSET NEMESだと文字エンコーディングを利用したSQLインジェクションに脆弱となる可能性があります。共有型サービスを利用されている場合、SET NAMESを使用している方も多いと思います。

ググってみると2005年11月には日本のMySQLユーザ会MLでは問題が認識されていたようです。