先日、gusagiさんより、bulletinHDについてのバグレポートとして、以下のURLを転送してもらいました。
http://ryus.co.jp/modules/d3blog/details.php?bid=107
先に結論から書くと、このエントリはMySQLの基本的なcase sensitiveルールを誤解していることによる、間違ったレポートです。
Quote:
この現象は、 Windows環境で作成したDBのデータをUNIX環境に持って行った場合に限定されます。
ただ、WARPなどの環境でデータを作成してから、UNIX環境にデータを移行して運用なんてケースも考えられるので、その場合は上記パッチを適用して頂いた方が良いと思われます。
SELECT (snip) WHERE dirname='PICO'
ALTER TABLE (prefix)_modules MODIFY `dirname` varchar(25) binary NOT NULL default '';
$constpref = '_MI_' . strtoupper( $mydirname ) ;
日本では年末に大掃除を行う習慣があります。
家中のガラス拭きをやった勢いで、altsysのmyblocksadmin機能について大掃除してみました。(半分嘘)
実際、myblocksadminは私が積極的にメンテしているコードの中では最悪クラスの汚さで、機能的にも、WYSIWYG対応もspawのみ、新コアについてもXOOPS2.2のみ、と半端でした。
どうやら本家はXOOPS2.2を切り捨てることを完全に決断したようで、2.3という番号を冠しながら、中身は2.0.18の改良版のようなので、XOOPS2.2対応はやめました。いろいろ問題のあるspawもやめてます。
その代わり、というわけではないのですが、ImpressCMSに正式に対応しました。これで、D3モジュール群がImpressCMSでストレスなく使えると思います。正直、本家版についてまで、動作確認している暇はないのですが、XOOPS_VERSIONを見て、2.3なら、ImpressCMSと同じ扱いにしています。もしブロックポジションなどの仕様が同じであれば、XOOPS2.3でもすんなり動くかもしれません。
もちろん、WYSIWYGはcommon/fckeditor(fckxoops)に対応しています。これが入っていなければ警告が出るという親切設計!
XCL2.1コアの機能で、ブロック編集画面で表示対象グループが選べる、というのも、絶対にあった方が利便性が高そうなので、ついでに実装してます。ただ、これをまともにやると、group_permissionテーブルのgperm_idが異常に増大しそうなので、表示対象グループに変更がなければ同テーブルはいじらない、なんてあたりにも一応手間をかけました。
まるまる書き直した関係で、バグもいろいろありそうですが、ベータ版等と分けて管理する余裕もないので、一発勝負で0.70としてリリースしてます。
もし不具合があったらコメント等の方法で教えてください。
xoops.org (Mamba) がこんなニュースを出しました。
Security : Protector Security Fix for XOOPS 2.0.x and 2.2.x users
先に結論から言うと、無意味なレポートなので、無視して構いません。
XOOPS_TRUST_PATH内のファイルにアクセスされたらLFIだ、なんてトンデモなレポートですから
この世の中には、DocumentRootの外に置く部分と中に置く部分が別れているアプリケーションはごまんとあります。
むしろそういうアプリケーションの方が正しい設計であり、全部をDocumentRoot内に置く古いXOOPSの構造こそある意味おかしいと言えます。
もし、前者のようなアプリケーションについて、DocumentRoot外に置かれるべきコードをDocumentRoot内に置いて、そこに直接アクセスされたとしたら、そりゃあゴロゴロと「脆弱性」が出てくるように見えるでしょう。
少なくとも、PathDisclosureくらいはいくらでもあります。
でも、誰もそんな馬鹿げたレポートはしません。
なぜなら、DocumentRootの内か外か、というのは非常に重要な違いであると言うことを誰もが知っているからです。
XOOPS_TRUST_PATH はDocumentRootの外に置く
これは大原則です。
こんなニュースを出すという時点で、xoops.org は誰もセキュリティの基本を知らないことを露呈してしまっています。
(ニュースだけならサイト管理者であるMamba氏が無知なだけでしょうけど、ご丁寧にもphppp氏がメールで問い合わせまでしてきてます)
翻って、ImpressCMSを見てみると、彼らはちゃんとXOOPS_TRUST_PATHの意味を理解していることが判ります。例えば、mainfile.php 内のパスワード部分を、XOOPS_TRUST_PATH内に別ファイルとして保存しています。
(本当に必要かどうかはともかく)
つまり、xoops.orgからリリースされるXOOPSという名前のCMSより、ImpressCMSの方がお勧めだと言えるでしょう。
serialize()/unserialize()
var_export()/eval()
A)安全性
この2つのペアを一見して判るのが、後者でeval()を使う怖さです。当たり前ですが、var_export()の出力であることが保証されているテキストでなければ、アンシリアライズしてはいけません。
もっとも、unserialize()についても、ちょっと古いPHPであれば、バッファオーバー脆弱性があったわけで、シリアライズテキストがリクエスト依存、という状況はいずれにせよあり得ないでしょう。
B)速度
結果から書いてしまうと、serialize()/unserialize() の方がだいぶ速いようです。
こんな感じのベンチプログラムで検証してみました。
#!/usr/local/bin/(php-cli binaries)
<?php
function getmicrotime()
{
list($usec, $sec) = explode(" ",microtime());
return ((float)$sec + (float)$usec);
}
function var_import( $data ) {
eval( '$ret='.$data.';' ) ;
return $ret ;
}
$data = ( big array ) ;
$time_start = getmicrotime();
for( $i = 0 ; $i < $_SERVER['argv'][1] ; $i ++ ) {
$serialized_data = serialize( $data ) ;
$restored_data = unserialize( $serialized_data ) ;
$serialized_data = var_export( $data , true ) ;
$restored_data = var_import( $serialized_data ) ;
}
$time_end = getmicrotime() ;
echo $time_end - $time_start , "sec. \n" ;
?>
PHPで配列やオブジェクトをシリアライズする際、一般に利用されているのはserialize()です。
しかし、serialize()されたテキスト形式が、結構やっかいです。
具体的には日本語などのマルチバイト処理と極めて相性が悪いのです。
もし、serialize()された状態で、テキストエンコーディングをEUC-JPからUTF-8に変更したりすると、もうunserialize()は効きません。フォーマットがバイト長に依存しているからです。
これだけなら、プログラミングレベルでカバーも出来るのですが、もっと厄介なのが、DBの自動エンコーディング変換とからむケースです。
たとえばXOOPSでは、セッションをDBに保存しています。そのセッションに日本語テキストをserialize()された状態で入れてしまうと、DBの自動エンコーディング変換で、テキストが元と別物になってしまうことがあります。MySQL4.1以上だと、内部的には常にUTF-8でデータを保持しています。EUC-JPのテキストに対しては、常にUTF-8への変換行われるので、EUC-JPとして取り出したとしても、実際には、
EUC-JP -> UTF-8 -> EUC-JP
という変換がかかっているのと同じです。そして、その際にどこかでバイト長がずれれば、unserialize()が効かなくなり、セッションが失われるわけです。
ここでクローズアップされるのが、PHPビルトイン関数だけで可能な、もう一つのシリアライズ方法です。
var_export()であれば、
array(
'index' => 'value' ,
)