タグ: PHP

ちょっと前にPHP 5.3のブランチが作られた、と書きましたが今度は前のマイナーバージョンもしばらくメンテナンスされます。どれくらいメンテナンスされるかは分かりませんが、メンテナンスされるのは良い事です。

PHP 5.3とPHP6の位置づけですが、基本的にPHP6 = PHP 5.x(最新版）- Unicodeサポートという形で合意が形成されているでPHP 5.xのマイナー版は機能追加が行われる予定です。

PHP 5.3がリリースされても慌ててPHP 5.2から5.3にアップグレードする必要はありません。ただし、PHP 5.2のサポートはそれほど長くはないので次々とPHP 5.xへとアップグレードする必要性がなくなる訳ではありません。

PHP 5.3は来年の第一四半期にリリース予定です。

PHP 5.3のブランチが出来ています。

個人用のアプリケーションなら、「Release fast, release early」でも良いと思いますが、フレームワークに近い言語が「Release fast, release early」だと困る方も多いと思います。互換性を維持しないアップグレードは1年に一回以内、出来れば18ヶ月か24ヶ月サイクルくらいに留めた方が良いと思います。

モジュールを別途配布するようにすればかなり現実的になるのですけどね…
PHP Core, PHP Standard, PECL, 3rd party, 程度に分けて管理すれば良いと思います。

とにかく、準備が必要な方はテストで使ってみては？

http://cvs.php.net/viewvc.cgi/php-src/?pathrev=PHP_5_3

遅ればせながらCore Graspのパッチを読みました。超ななめ読みなので勘違いしているかも知れません。間違っていたら教えてください。

一番興味があったのはSQLインジェクションの自動検出はどうなっているのかです。以下の関数がSQLインジェクションチェックに利用されています。

+int grasp_check_query(zval *z)
+{
+	char *c,*s;
+	int i,j,l;
+	char q;
+
+	if (grasp_isfull_p(z)) return 0;
+	if (!grasp_isptr_p(z)) return 1;
+	if (z->type != IS_STRING && z->type != IS_CONSTANT) return 1;
+	
+	
+	l = z->value.str.len;
+	c = z->value.str.val;
+	s = z->secmark;
+
+
+	for(i = 0; i<l; i++)
+	{
+		if (s[i] && (c[i]=='-'))			
+		{
+			i++;					
+			if(!(c[i] < '0' || c[i] > '9')) 
+			{
+				for(i;i<l;i++)			
+				{
+					if (c[i] < '0' || c[i] > '9')
+					{
+						if (!s[i])
+							break;	
+						else
+							return 0; 
+					}
+				}
+			}
+			else
+			{
+				return 0;
+			}
+			if(i == l) return 1;
+		}
+		
+
+		if (s[i] && (c[i] < '0' || c[i] > '9')) return 0;
+		
+		if (c[i] == '¥¥')
+		{
+			i++; 
+			if (s[i]) return 0;
+		} else
+		if (c[i] == '¥'' || c[i] == '¥"' || c[i] == '`')
+		{
+			q = c[i];
+			for(i++; i<l; i++)
+			{
+				if (c[i] == '¥¥')
+					i++; else
+				if (c[i] == q)
+					break;
+			}
+			if (i<l && s[i]) return 0;
+		} 
+	}
+	return 1;
+}

どうも文字列の各文字が安全かチェックして安全でない場合はエラーにしているようです。単純に「この文字列（ZVAL）は関数で処理済みで安全」とマークしている訳でないようです。

ではmysql_real_escape_stringとかを拡張して安全マークを追加しているのかな?と思ったらしていないようです。代わりにaddslashesが拡張されていました。

PHP_FUNCTION(addslashes)
 {
 	zval **str;
+#ifdef HAVE_GRASP
+	char *res, *secm;	
+#endif
 
 	if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &str) == FAILURE) {
 		WRONG_PARAM_COUNT;
@@ -2884,11 +3266,23 @@ PHP_FUNCTION(addslashes)
 	if (Z_STRLEN_PP(str) == 0) {
 		RETURN_EMPTY_STRING();
 	}
+#ifdef HAVE_GRASP
+	grasp_normalize(*str);
+	res = 0;
+	secm = 0;
+	//grasp_setptr_p(return_value, zend_get_parameters_secmark());
+	res = php_addslashes_secmark(Z_STRVAL_PP(str),
+	                             Z_STRLEN_PP(str), 
+	                             &Z_STRLEN_P(return_value), 0, &secm, Z_SECMARK_PP(str)
+	                             TSRMLS_CC);
 
+	RETURN_STRING_SECMARK(res, 0, secm);
+#else
 	RETURN_STRING(php_addslashes(Z_STRVAL_PP(str),
 	                             Z_STRLEN_PP(str), 
 	                             &Z_STRLEN_P(return_value), 0 
 	                             TSRMLS_CC), 0);
+#endif
 }

マルチバイト環境ではaddslashesによる文字列エスケープは厳禁な（SQLインジェクションに脆弱になる場合がある）ので実装的には不十分です。

GraspはPHP用のtaintモードとして紹介されていますが、Perl, Rubyなどの一般的にtaintモード呼ばれている機能と多少異なります。

http://www.cs.virginia.edu/~evans/pubs/infosec05.html

に記載されているようなtaintモードになっているようです。
# この論文もななめ読み

具体的には

$sql = “SELECT * FROM table WHERE id = “. $id;
mysql_query($sql);

の様なコードでも$idが危険な文字列かつ攻撃コードを含んでいれば、エラーになります。つまり、$sql文字列中の$id部分が安全かどうかチェックできるようになっています。

例えば、

if (ereg(“[0-9]+”, $_GET[‘id’]) {
$id = $_GET[‘id’];
}

の様にプログラマのミスにより$idが危険な変数になっていても攻撃が回避できます。

完成度が高くなれば通常のtaintモードとは比べ物にならないくらい安全性の向上が期待できると思います。しかし、パッチを超ななめ読みした感じでは実用的になるまでもうしばらく時間が必要な気がしましたが、順調に開発が進めばかなり便利な機能になると思います。
# 現状の実装だど文字エンコーディングがSJIS等の場合はSQLインジェクション
# と誤検出すると思います。addslashesなので元々SJIS等の事などまったく考慮
# されていなくて当たり前です。マルチバイト文字の事は考えてないようですが
# UTF-8ならそれなりに使えそうです。

SQLインジェクションは対策が簡単ですが、XSSは適材適所で対応が分かれるので精度の高い対策は難しいです。しかし、LDAP/XPATH/XQuery等のインジェクション攻撃は基本的にSQLインジェクションと同じレベルで対応可能です。半年後くらいにまたパッチを見てみよう。

「なぜPHPアプリケーションにセキュリティホールが多いのか？」をテーマにした技術評論社のブログ風の記事を書いています。

一番新しい

http://gihyo.jp/dev/serial/01/php-security/0008

ですが、自分で防いだつもりのセキュリティホールは実は防いだ事になっていなかった、アプリケーションが多く在りました。というより今でも作り続けられています。原因は「サニタイズ」による脆弱性の回避であるものが多いです。なので「サニタイズ」ではなく「バリデーション」と「適切なエスケープ」によって対策すべきです、と書きたかったのですが「エスケープ」の部分を書いてないですね。バリデーションの時に説明するつもりですが、確かに尻切れとんぼのような感じです。

編集の方からこんな感じなのですがどうなんでしょう？メールが来ていました。

http://b.hatena.ne.jp/entry/http%3A//gihyo.jp/dev/serial/01/php-security/0008

と言う感じで何やら否定的なコメントが多いようです。

最初に

今回は熟練したWebアプリ開発者なら常識のクロスサイトスクリプティング対策の落とし穴を紹介します。

と書いているのですがどうも「熟練のWebアプリ開発者なら常識」としている前提が伝わっていなかった？のか記事自体に問題がある？のか理由がいまいち分かりません。

ブックマークしている方を見るとセキュリティ系で有名な方もいます。初心者向けのブログなのであまり一般受けしないエントリはこのブログの方が多はずです。（と言ってもこちらにもあまり役に立つことはあまり書いてませんが）いまいち理由がよくわからないのでもし知っている方教えてください。

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

http://qa.php.net/

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

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

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

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で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)

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

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

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