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に入れないようにした方が良いようです。基本的な事ですが、探しても情報が見つからなかったので書いておきます。

Session Adoptionが攻撃に有用な実例

PHP:既知のセキュリティ脆弱性 – Session AdoptionでWebmailアプリケーションであるSquirrelMailとRoundCubeがこの攻撃に脆弱であることを紹介しました。

タイミング良く(?)同じくPHPベースのWebmailアプリであるIMPにクロスサイトスクリプティング脆弱性が発見され修正されました。(IMP-4.3.3未満/IMP-4.2.2未満)

試しに、ソースコードをチェックしてみました。
“Session Adoptionが攻撃に有用な実例” の続きを読む

In Session Phishing

In Session Phishingという興味深いアドバイザリが公開されています。

具体的な記載はありませんが、現在広く利用されているInternet Explorer, Firefox, Safari, ChromeでJavaScriptを利用するとユーザが特定のサイトにログインしていたか判別できるようです。

Recently Trusteer CTO Amit Klein and his research group discovered a vulnerability in the JavaScript engine of all leading browsers – Internet Explorer, Firefox, Safari, and Chrome – which allows a website to check whether a user is currently logged onto another website. The source of the vulnerability is a specific JavaScript function. When this function is called it leaves a temporary footprint on the computer and any other website can identify this footprint. Websites that use this function in a certain way are traceable. Many websites, including financial institutions, online retailers, social networking websites, gaming, and gambling websites use this function and can be traced.

ユーザが訪問したことがあるサイトを検出する方法はあります。訪問済みのURLは色が変わることを利用して検出します。マーケティング目的で実際に利用されています。しかし、この方法ではユーザが実際に今ログインしているかどうかは判別できません。アドバイザリによると、ログインしているかどうか判別できる足跡が検出できる、としています。

自分がサイトにログインしている最中に「現在、攻撃されている可能性があるので再ログインをしてください」とメールを送ればより効果的なフィッシングが行えます。

もうしばらくすれば詳細が明らかになるかも知れませんが、最近のブラウザ全てに影響するようなのでJavaScriptやDOMの仕様に関係する問題の可能性が高いです。その場合は簡単に修正できない可能性がかなり高いのではないかと思います。

フィッシングでなくてもマーケティング目的で利用されそうな気もします。

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に共通する脆弱性です。

最近、影響範囲はかなり狭くなりましたが、まだまだ注意が必要な脆弱性であり、根本的な解決にはパッチと適切なセキュリティ対策が必要です。

“PHP:既知のセキュリティ脆弱性 – Session Adoption” の続きを読む

文字エンコーディングとセキュリティ(3)

gihyo.jpのブログ型の連載である「なぜPHPアプリにセキュリティホールが多いのか?」の

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

で、PHPのサンプルコードを書いているのに「JavaScriptなど」とJavaScript用のサンプルコードであるかの様に書いていました。

JavaScript -> PHPに書き換えても良いのですが、両方JavaScriptのサンプルを掲載するように編集者の方に依頼しておきました。

ご指摘頂いた方、ありがとうございます。

PHP4.4.9のセキュリティ状態

PHP4のサポートは2008/8/8を持って終了しました。サポート終了に合わせて、最後のPHP4リリースとなる4.4.9がリリースされています。サポートが終了していますが、稼動中のPHPの半分はまだPHP4であるとる統計情報もあり、まだまだ現役です。

PHPプロジェクトのサポート終了したため、PHP 4.4.9のセキュリティ脆弱性はCVEなどでも報告されなくなりました。この為、普通にセキュリティ情報を収集していてもPHP4.4.9に対する脆弱性情報は入手できません。

“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開発者とユーザが知っておくべきシェルコマンドエスケープの内部処理

これから紹介する脆弱性はPHP 5.2.6で修正されています。修正された、とは言え注意が必要です。

PHPは古くからシェルコマンドとシェル引数をエスケープ処理する為に、escapeshellcmd関数とescapeshellarg関数を提供しています。

この関数はマルチバイト文字にも対応しているのですが、ビルドや環境によっては対応できていないときがあります。
“PHP開発者とユーザが知っておくべきシェルコマンドエスケープの内部処理” の続きを読む