第3回 はじめてのZendFrameworkアプリケーション
第3回 はじめてのZendFrameworkアプリケーション がgihyo.jpで公開されています。
http://gihyo.jp/dev/serial/01/zf-ajax/0003
コメント、質問、不具合など、気づかれた事がございましたらコメントを頂けると助かります。
次回はこのダメダメな初めてアプリケーションを少しマシにします。
その次は4/30にリリースされたZend Framework 1.8の紹介をします。
Zend_Toolの使い方 – パスに入れない
Zend_ToolのzfコマンドがZendFrameworkのバージョンによって使えたり、使えなかったりする問題で困っていたのですが原因が分かりました。
Zend_Toolのzfコマンドでプロジェクトを作成すると
$ zf create project
ZendFrameworkのファイルをカレントディレクトリのlibraryに全てコピーします。プロジェクトの雛形にはapplication/boostrap.phpが含まれ、ここでinclude_pathが設定されます。boostrap.phpは、エントリポイントとなるpublic/index.php
// @see application/bootstrap.php
$bootstrap = true;
require ‘../application/bootstrap.php’;
から毎回必ず呼ばれるので
// you may wish to add other paths here, or keep system paths: set_include_path(‘../library’ . PATH_SEPARATOR . get_include_path()
set_include_path(‘../library’);
ZendFrameworkのアーカイブはどこに展開しても構わないようになっています。
この事は知っていたのですが、zfコマンドを使わないでZendFrameworkを使えるよう、PEARをインストールしたディレクトリにlibrary/Zendディレクトリをコピーし、デフォルトのphp.iniでinlcude_pathに設定してZendFrameworkを使うようにしていました。
これがどうもダメだったようです。Zend_Toolのディレクトリ構成を見て、似通った構成だったのでもしかして、と思いinclude_path設定を変えて試してみました。すると動かないと思っていたバージョンでもzfコマンドが動作するようになりました。インクルードパスにZendFrameworkのライブラリをパスにいれると、意図しないスクリプトが読み込まれてエラーになったりしていたようです。中途半端に動く物もあったりしたのでですが「previrew版だから仕方ないか」と思って詳しく調べていませんでした。これで一つすっきりしました。
Zend_Toolを試す場合、ZendFrameworkのZendディレクトリはinclude_pathに入れないようにした方が良いようです。基本的な事ですが、探しても情報が見つからなかったので書いておきます。
PHP:既知のセキュリティ脆弱性 – Session Adoption
追記：より新しい情報については間違いだらけのHTTPセッション管理とその対策をどうぞ。
PHPには広く知られているにも関わらず放置されている既知のセキュリティ脆弱性が幾つかあります。その一つがセッションモジュールのセッションアダプション(Session Adoption)脆弱性です。この脆弱性は現在広く利用されているWebアプリケーションの安全性に、非常に大きな影響を与える脆弱性です。
セッションアダプション脆弱性とはセッション固定化攻撃を可能とする脆弱性の一種です。セッションアダプションに脆弱なセッション管理システムは、ユーザ(ブラウザ)が送信してきた未初期化のセッションIDを受け入れ、セッションを初期化してしまいます。PHPに限らず、RailsやJavaのフレームワーク等、多くのWebフレームワークに発見されている脆弱性です。
セッションアダプション脆弱性を利用すると、攻撃者は長期間に渡って他人のIDを使う成りすましが可能になる場合があります。IDを盗みたい犯罪者には利用価値の高い脆弱性です。
この脆弱性は、10年以上前から問題視されている国別TLD(ccTLD)の属性ドメイン(国別Top Level Domain, co.jp, or.jpなどのドメイン)にも下位ドメインからクッキーが設定でき、サブドメインのクッキー設定が無視される(送信順序、優先順位がいい加減)、というとんでも無いクッキーの仕様と組み合わせると、大量の他人のユーザセッションIDを取得(設定)し、成りすます事ができます。
セッションアダプション問題は全てのPHP、PHP 4.4.9/PHP 5.2.8/PHP 5.3/PHP 6.0に共通する脆弱性です。
最近、影響範囲はかなり狭くなりましたが、まだまだ注意が必要な脆弱性であり、根本的な解決にはパッチと適切なセキュリティ対策が必要です。
PHP4.4.9のセキュリティ状態
PHP4のサポートは2008/8/8を持って終了しました。サポート終了に合わせて、最後のPHP4リリースとなる4.4.9がリリースされています。サポートが終了していますが、稼動中のPHPの半分はまだPHP4であるとる統計情報もあり、まだまだ現役です。
PHPプロジェクトのサポート終了したため、PHP 4.4.9のセキュリティ脆弱性はCVEなどでも報告されなくなりました。この為、普通にセキュリティ情報を収集していてもPHP4.4.9に対する脆弱性情報は入手できません。
ZendFrameworkで作る『イマドキ』のWebアプリケーション
技術評論社さんのPHPセキュリティ関連のブログ、なぜPHPアプリにセキュリティホールが多いのか?も執筆させて頂いていますが、新しくZendFrameworkで作る『イマドキ』のWebアプリケーションも執筆させていただくことにになりました。
今回の連載では私のブログでフィードバックや質問をお聞きしようと考えています。一般的な質問はMLなどでお聞き頂けるようお願いしますが、動作しない、動作がおかしい、説明がわかりづらい、これを説明してほしい、など記事に関連するご意見やご質問をお待ちしています。
Wikiにサポート用のページも用意しました。Wikiにはまとめや必要なリソースへのリンクなどを掲載します。
http://wiki.ohgaki.net/index.php?ZendFramework-Web-Application
今回、連載を開始するにあたりLinux, Mac, Windowsでできる限り同じ環境が作れるように工夫してみました。
当初はXAMPPをベースとした環境にしようと思ったのですが、64bit版が用意されていないのは現在のPC環境を考えると好ましくありません。そこで、PostgreSQLのバイナリ配布版であるPostgreSQL One-Click Installerを利用した環境を利用することにしました。PostgreSQL One-Click Installerを利用すると、Linux, Mac, Windowsでほぼ同じApache/PHP/PostgreSQLの動作環境を構築できます。
CentOS5を利用している環境が公開可能であるため、VMwareイメージも公開しています。VMwareイメージには以下のパッケージが含まれ、必要な設定が行われています。
– CentOS 5.2
– Apache 2.2
– PHP 5.2
– ZendFramework 1.7
– PostgreSQL 8.3
– Eclipse 3.4
– Mercurial 1.1
ダウンロード先など、詳しい情報はWikiをご覧下さい。
エンティティ化された文字による任意コード実行
小泉さんが発見され昨年末に公開された脆弱性です。詳しくはアドバイザリをご覧いただくとして概要を解説します。
CVE
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-5557
アドバイザリ
[Full-disclosure] CVE-2008-5557 – PHP mbstring buffer overflow vulnerability
かなり特殊な設定といえる状況で問題となるようですが、ちょうどgihyo.jpで文字エンコーディングに関連したセキュリティ問題を解説しているので紹介します。
http://gihyo.jp/dev/serial/01/php-security/0019
http://gihyo.jp/dev/serial/01/php-security/0020
現行版のPHPに任意メモリ参照バグ – 攻撃コード付き
随分前から共有型Webホスティングサービスでは安全性を確保できないので、安全性を重視するサイト(ECなど)は最低限でも仮想ホスト型の共有サービスを利用すべきである、と言っています。
今回のエントリはPHPをApacheモジュールで共有型ホスティングサービスを利用しているユーザに影響します。SSLを利用している場合は秘密鍵を盗まれます。このバグはPHP 5.2.8でも修正されていません。当然ですがPHP 4.4.9でも修正されていません。
もっと読む
PHP開発者とユーザが知っておくべきシェルコマンドエスケープの内部処理
これから紹介する脆弱性はPHP 5.2.6で修正されています。修正された、とは言え注意が必要です。
PHPは古くからシェルコマンドとシェル引数をエスケープ処理する為に、escapeshellcmd関数とescapeshellarg関数を提供しています。
この関数はマルチバイト文字にも対応しているのですが、ビルドや環境によっては対応できていないときがあります。
もっと読む
PHP 5.3の名前空間仕様が変更されました
名前空間に関する議論は5年以上も行われていたのですが、今度こそ結論が出たようです。
何故このようなエントリを書くかというと、Software Design（技術評論社）の11月号にPHPの最新情報としてα版PHP 5.3を紹介しているからです。入稿後に仕様変更があったので最新号の記事ですが既に内容が古くなってしまいました。
# とは言ってもまだ新しい仕様のPHPは無いですが
α版なので仕様や機能が大きく変更される事もありますが大きな変更がありました。見本誌が刷り上がった頃に名前空間の区切り文字が”::”だと静的にメソッドを呼び出す場合やクラス定数を呼び出す場合に困る場合がある、とPHP開発者のMLで議論になり始めました。
もっと読む
PHPのSessionモジュールの脆弱性
たまたま目に止まったブログがあるので紹介します。
PHP:session_set_save_handlerリファレンスマニュアルのサンプルにパス・トラバーサル脆弱性
http://www.tokumaru.org/d/20080818.html#p01
[php]session_set_save_handlerのパストラバーサルで任意コマンドの実行が可能
http://www.tokumaru.org/d/20080819.html#p01
この危険性はStrict Sessionパッチが作られた頃にも議論されていました。このパッチを摘要するとセッションアダプション脆弱性も修正します。もし、互換性なので要件で厳格なSession管理ができない場合でもセッションIDに利用可能な文字は安全な文字のみに限定されるのでパストラバーサルなどの問題は発生しません。
話は横道にそれますが、セッションアダプションの問題については、PHP 4.4.9リリース前にPHP Security Response Teamと議論しました。リリースノートを見れば解りますが、残念ながら良い結果ではありませんでした。いくつかの脆弱性をレポートしましたが、その内の一部の脆弱性のみに対応しただけです。これについては時間が出来次第エントリを書きます。
話を戻しますが、セッションモジュールの問題は随分前（何年も前）に議論されており、開発者のスタンスとしては「ユーザ側の問題」「ファイルストレージがあるのに態々自分作って自分の足を打つようなユーザが問題」「RDBMSをストレージに使ってエスケープしないでSQLインジェクションされるのと同じ」といった結論になってしまったと記憶しています。
セッションアダプションの問題を解決すれば、パストラバーサルの問題もSQLインジェクション問題も解決するのですが…
セッションアダプション脆弱性はリスクが不当に低く評価され過ぎです。PHPを利用されている方全てにStrict Sessionパッチをお勧めします。
未修正のPHP脆弱性を募集
PHP4のサポート終了に伴い、幾つかの未修正のセキュリティホールについてPHP Security Response Teamとやり取りしています。
ついでなので出来る限り多くの脆弱性が修正されるようにしたいと考えています。PHP4.4.8, PHP 5.2.6で未修正の脆弱性やセキュリティ上の問題をご存知の方は是非教えて下さい。
現時点はどの脆弱性をレポートしているのか書けませんが、もしPHP本体やモジュールで修正されていない脆弱性をご存知の方は教えて頂けると助かります。メールやこのブログのコメント、このブログのContactページ等からご連絡ください。
結果については後日このブログにて公開します。
PHP 4.4.8用のStrict Sessionパッチ
桝形さんから
http://blog.ohgaki.net/php-5-2-strict-session
で公開したパッチのPHP4.4.8版を送っていただきました。私のWikiにも添付ファイルとして掲載させていただきました。
http://d.hatena.ne.jp/masugata/20080714#p2
に掲載されているパッチと同じパッチです。
私は全てのPHPユーザがStrict Sessionパッチ適用すべきと考えています。詳しくはWikiをご覧ください。
http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2FStrictSession
桝形さん、パッチありがとうございました。
APCにStack Overflow脆弱性
件名の通り、APCのStack Overflow脆弱性が公開されています。
http://sla.ckers.org/forum/read.php?3,21615,21615#msg-21615
このポストに書いてある通り、PHP4ではインクルード攻撃に脆弱なアプリならallow_url_fopenをoffにしていても効果はありません。PHP4+APCを使っている方は今すぐAPCをCVSバージョンにバージョンアップするか、APCをロードしない方が良いでしょう。
MomongaLinux等、パッケージをビルドする際にstack smashing attackから防御するstack protectorオプションを使ってビルドしているバイナリであればリンク先の攻撃方法では攻撃できません。しかし、インクルード攻撃に脆弱であれば、他の脆弱性を利用してカナリア値を盗む事も可能なので安全とは言えません。いずれにせよAPCを利用している場合はバージョンアップする方が良いでしょう。
追記：
CVSを見てみました。
http://cvs.php.net/viewvc.cgi/pecl/apc/apc.c?r1=3.20&r2=3.21
fileinfoがスタック変数、strcpyでオーバーフローしてます… 教科書通りの解りやすい脆弱性です…
Taint mode for PHP 5.2.5
PHPのTaintモードパッチです。最近更新されていたようです。
ftp://ftp.porcupine.org/pub/php/php-5.2.5-taint-20080130.README.html
Taintモードはあれば良い程度の機能ですが、フールセーフ機能（フェイルセーフでなくフールセーフ – fool safe）としては便利です。入力バリデーション用のコードは必須ですが、そのようなコードが無い場合やあっても不完全な場合には有用です。
PHP 5.2.5よりCVS HEADとPHP_5_3ブランチ用のパッチを作った方が採用されやすいのですが….
このパッチは関数毎に違うマークを付けるtaintモードなのでかなり大きいです。(+遅い）
企業ユーザはPHP4からPHP5への移行は慎重にすべき
2008年1月3日のPHP4.4.8のリリースを持ってPHP4サポートが終了しました。海外では「PHP5へ移行しよう」キャンペーンも始まりました。
私は従来から「PHP5へ早く移行すべきです」と繰り返し勧めて来ました。現在でも全てのオープンソースアプリケーションの開発者は、今すぐPHP5に移行すべき、と考えています。
しかし、新規開発を除き、企業ユーザには今すぐPHP5へ移行すべきだ、と一概にアドバイスできません。3つのお薦めしない理由があります。
- PHP4からPHP5へのマイグレーションはそれほど簡単ではない
- PHP5に移行するとマイナーバージョンアップに追随しないとならない
- PHP5.3のリリースが準備されている