今年も「FuelPHP Advent Calendar」が開催される季節になりました。
アドベントカレンダーって何？という方は、gihyo.jpの記事（2010/12/1）を参照願います。
なお、過去のアドベントカレンダーは、一昨年は技術評論社から、去年は達人出版会から電子書籍として出版されています。無料で取得できますので、FuelPHPに興味のある方は、是非、ご覧ください。
また、今年も達人出版会から出版していただくことが決まっていますので、参加者（先着25名）は自分の著作を達人出版会から出版した著者ということになります。
参加したい方は、お早めに以下のサイトから参加登録してください。
FuelPHPには複数環境に対応するための仕組みが最初から用意されています。
本番環境に設定した場合、基本的にはエラーを画面に表示しないようになっています。
動作環境のモード指定はFuel::$envにより決まり、デフォルトで
が定義されています。
デフォルトの環境はFuel::DEVELOPMENT（開発環境）になります。
FuelPHPの動作環境はfuel/app/bootstrap.phpの以下で決定されます。
/**
* Your environment. Can be set to any of the following:
*
* Fuel::DEVELOPMENT
* Fuel::TEST
* Fuel::STAGING
* Fuel::PRODUCTION
*/
Fuel::$env = (isset($_SERVER['FUEL_ENV']) ? $_SERVER['FUEL_ENV'] : Fuel::DEVELOPMENT);
つまり、本番環境の環境変数FUEL_ENVにproductionを設定しておけば、本番環境モードになります。指定がない場合は、Fuel::DEVELOPMENTになるようになっています。
Apacheの.htaccessで環境変数を設定する場合は、public/.htaccessにある以下のコメント行を有効にすればokです。
# SetEnv FUEL_ENV production
なお、環境変数を設定できない場合や設定したくない場合は、$_SERVER['SERVER_NAME']などから本番環境かどうかを判定するように上記のコードを変更するのがよいでしょう。
そして本番環境では、FuelPHPがエラーを検知しても、詳細なエラーメッセージは表示されず、デフォルトだと以下のようなそっけないメッセージが表示されます。
開発環境モードなど他のモードでは、お馴染みの以下のようなエラーメッセージが表示されます。
ただし、public/index.phpで
/**
* Set error reporting and display errors settings. You will want to change these when in production.
*/
error_reporting(-1);
ini_set('display_errors', 1);
となっているため、本番環境モードに設定してもParseエラーなどが表示される可能性は残ります。必要な場合は、上記のdisplay_errorsも本番環境では0に変更しておくとよいでしょう。
「WordPress Securityを考える会 vol.3」が10/26(土)に名古屋でありましたので、参加しました。
レガシーコードが一部で問題視されているWordPressですが、プラグインについては、さらに悲惨な状況のようです。
まず、プラグイン作成に関する資料が整備されておらず、プラグインの実装はかなり実装者依存のようです。WordPressで用意されている関数などを使えば、かなりセキュアなコードになる部分でも、そもそもWordPressの関数の存在を知らずに独自に実装していたり、WordPressの関数を使っているが、使い方が間違っており安全になっていないような事例もあるようです。
プラグインのコードはWordPress本体の比でなくレガシーなものもあるようですが、そもそも、コードを見ている人がほとんどいないようで、実装者のスキルが上がらない限り改善の可能性は低そうです。ダウンロード数が多くても、有名な企業が作成していても、それだけでは安心はできないようです。
WordPress公式サイトに登録されているプラグインでも、セキュリティ上安心とは言えず、プラグインの評価（Rating）もほぼすべてがユーザ視点の使い勝手のみの評価なので、コードがセキュアかどうかはわかりません。
少し前に、Top 50プラグインの脆弱性についてのレポートがありましたが、20%のプラグインには脆弱性があったようです。Top 50でその割合なので、ユーザが少ないプラグインはさらに悲惨な状況であることが予想されます。
もし、WordPressのプラグインの利用について指針を示すとすると、
となると思いました。が、これは非常に敷居が高く、一般的なWordPressユーザにとっては現実的ではないとも思いました。
もし、このあたりの状況の改善にコミットする気がある人がいたら、まず、プラグイン作成のガイドラインをもっと整備したり、お手本となるプラグインを示すなどして、きちんとしたプラグインの作成方法がわかるようにする必要があるでしょう。それと同時に、現在あるプラグインのコードをレビューして脆弱性を地道にIPAに報告していくしかないのかなと思います。
