Jeans CMS 製作日記 自分のための次世代CMS製作メモ

RSSフィードで購読なさっている方へ：アンケートにご協力お願いできますでしょうか。

Jeans CMSにおいては、いくらか規約を設けることでセキュリティーを確保する予定です。ただ、規約があまりにも複雑で敷居が高すぎる場合、その規約が守られないことになってしまいます。過ぎたるは及ばざるが如しにならないように、うまく規約を設定する必要があります。

SQLインジェクションを防ぐため、SQLクエリー実行部分のスクリプトの記述に関して規約を作る必要があるのですが、ここでプリペアードステートメントを使用することを規約とするかどうか、悩んでいます。

例えば、次のスクリプトは、現在のNucleusで使われている様式です。

コード０：現在のNucleus様式

$res=mysql_query(
    'SELECT i.itime as itime, c.cblog as blogid, substr(i.itime,0,4) as year, substr(i.itime,5,2) as month, substr(i.itime,8,2) as day, '.
    'FROM jeans_item as i, jeans_category as c '.
    'WHERE i.icat=c.catid AND c.cblog='.intval($blogid).' '.
    ' AND c.catid='.intval($catid).' '.
    'ORDER BY i.itime DESC LIMIT '.intval($limit));

<アンケートにご協力お願いします のつづき>

coreクラスは、config.phpをインクルードしたときに一番初めに定義されるクラスだ。今、このcoreクラスをすべてのクラスの基底クラスにするかどうかで悩んでいる。

例えば、プラグインで文字出力を行う場合、現在の仕様では

core::p($text);
core:echohtml('<p>id: <%1%></p>',$id);

のように記述するが、coreクラスを基底クラスとしてプラグインクラスを作成すると、

$this->p($text);
$this->echohtml('<p>id: <%1%></p>',$id);

のように記述してもよいし、

self::p($text);

のように記述することもできる。PHP5ではメソッドのオーバーライドができないように設定できるから、プラグインでpメソッドやechohtmlメソッドを書き換えて変なことをするのも禁止できる。

<coreを基底クラスに？ のつづき>

プラグインオプションの値は、plugionoptionクラスのオブジェクトに保持させることにした。

pluginクラス内にて、

$this->option=new pluginoption($this->id);

もしくは、

public function blogoption($bid){
    $obj=new pluginoption($this->id,'blog',$bid);
    return $obj;
}

のように使う。

<pluginoptionクラス のつづき>

現在のところ、コアではほとんどのコードでクラスのスタティックメソッドを利用するため、あまりオブジェクト指向とはいえないコードになっている。

一方で、プラグインの部分は、オブジェクト経由でアクセスする予定。理由は、次のとおり。

Nucleusと同じく、プラグインはすべてpluginクラスを継承したクラスとして記述することになる。プラグインのクラスをスタティックなメソッドの集合体として扱った場合、複数のプラグインのクラスが単一のpluginクラスを継承しているため、親クラスであるpluginクラスのそれぞれのメソッドで、各プラグインに固有の値（プラグインオプションなど）を処理できないのである。

一方で、Nucleusがやっているようにすべてオブジェクト経由で扱った場合、pluginクラスのメソッドでは$thisオブジェクトを経由することでこれを行うことができる（他方、コアの各クラスは、複数のインスタンスを持たせる必要が無いため、スタティックなメソッドやプロパティを扱うやり方で、今のところコードに混乱は無い）。

プラグインの仕様については、Nucleusのプラグインとほぼ同一のものを提供する予定である。が、もともとこのプロジェクトをはじめた動機のひとつとして、プラグインを書くときに楽をしたいというのもあるので、そうなるような仕様の変更を考えている。

現在のところ、どんなことで楽ができるかというと、

１）sql_table() 関数を使う必要が無い。
２）global $manager, $CONF, $DIR_LIBS; といった記述が不要。
３）echo htmlspecialchars($text,ENT_QUOTE,_CHARSET); の代わりに core::p($text); で良い。
４）３と同様だが、クエリーでaddslashes()やmysql_escape_string()なども使う必要が無い。

など。

<プラグイン周りの仕様 のつづき>

先の記事もそうであるが、セキュリティー対策のためのコードをいくつか追加したので、改めてメモ。

１）SQLインジェクション対策
　sql::query()メソッドで、簡易プリペアードステートメントを使う。MySQL5やPostgreSQLほど本格的なプリペアードステートメントではないが、この方法でほぼ１００％、SQLインジェクションは防げる。SQLステートメントでフィールド部分を入力値にしたがって変更したい場合は、core::fill()メソッドを用いて正規表現でホワイトリスト形式で入力値をチェックしながら値を挿入する。

２）XSS対策
　core::echohtml()メソッドで、プリペアードステートメント様の機能が使える。正規表現で入力値をチェックすることも可能。

３）リモートスクリプトインクルード対策
　クラス名を適切に選んでおけば、PHPファイルのインクルードはコアが自動的に行ってくれる。include, require などのステートメントを使うことはほとんどないはず。

４）ディレクトリトラバーサル対策
　file_exists()の代わりに、core::checkFile()メソッドを使用する（下のコードを参照）。

５）ヌルバイト攻撃対策
　リクエストにヌルバイトがあると、コア呼び出し時に自動的に停止する（先の記事のコードを参照）。

<セキュリティー対策、あれこれ のつづき>

$_GET, $_POST, $_COOKIE 使用時の規約を定めることにした。こうすることで、少ないリソース量で有効なセキュリティ対策が行える。

１）キー名が『binary』で終わる場合以外は、ヌルバイトは使用禁止。
２）キー名が『id』で終わる場合は、数値のみを利用。
３）キー名が『path』で終わる場合、URLもしくはファイルなどのパスを指定できる。ただし、日本語使用不可。
４）キー名が『text』で終わる場合、ヌルバイト以外なら何でも使用可。
５）上のどれにも当てはまらない場合、英数字、ピリオド、ハイフン、アンダースコア、スラッシュおよび日本語のみが使用可能。
６）URIに『#』および２つ以上の『?』を含むものを禁止。

（080208 改定）
キー名が『binary』で終わる場合に、ヌルバイトを受け付けるようにした。また、６）の条件を追加した。

<リクエストに関する規約 のつづき>