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

またまた、スクラッチから構築中。以前考えていた（そしてコードを挿入していた）さまざまな機能をとりあえず削除し、必要最低限のコードでどこまでできるかを考えている。かなりコードがすっきりしそう。例えば、新しい考え方では、コード中でのスキンとテンプレートの区別がまったく存在しない等（ただし、概念上の違いは存在）。

サポートする文字コードは、UTF-8のみにすることにした。これも、コードの簡潔化のため。その他、さまざまな規約を設けることで、簡潔なコードでの完成を目指す。今月は、Jeans月間かな？

で、表題の件。文字コードの問題は主に、XSS対策でのこと。２つ考え方があって、ひとつはJeansに入力される文字列をチェックする方法。もう一つは、出力するときにチェックする方法。

<文字コードの問題 のつづき>

先日取り上げた複数ユーザで使用時のアイテムパースでの脆弱性の回避について、結論が出せた。

やはり、ホワイトリストで対処するのが一番確実なやり方なので、利用可能なタグをホワイトリストで用意し、それに該当しないものはずべてhtmlspecialchars()互換の方法で無効化することにした。

<restriction::restrictHtmlTags()メソッド のつづき>

久々の更新。

先日、とあるPHPの本を読んで知ったのだが、HTMLへのPHPコードの挿入は、<?php ... ?>以外に、<script language="php">...</script>でもできる。PHP5でもこれを確認した（PHP6ではどうだか知らない）。

現在のバージョンでは、それぞれのアイテムのパースにもevalを使っている。admin以外でのPHPコードの実行を回避するために、『<?』を『&lt;?』に変換しているが、これだけでは穴があるということになる。

<itemをevalするのはまずいかも のつづき>

現在、Jeansの開発はすこしお休み中。気分転換にoyagameを作っていて、そちらが出来ればまたJeansに戻る予定。Jeansの開発を続けていて、これは今までやって来たプログラミングの中で、最も大変なプロジェクトだと気がついた。あせらず、ゆっくりやりたい。

さて、Jeansの骨格部分はあらかた仕上がっているので、ここでもう一度セキュリティーをチェックするため、『PHPサイバーテロの技法』を読んで、問題（になるかも知れない）部分をピックアップしてみた。

<セキュリティメモ のつづき>

ほぼ一ヶ月ぶりの更新。現在、デフォルトスキンを表示させるスキン変数周りの整備中。インデックスページは、コメント機能以外は表示できるようになった。

さて、webサーフィンしていて見つけたセキュリティー情報のメモ。

httpOnlyをFirefoxで
PHP 5.2でクッキーのhttpOnlyフラグがサポートされるみたいです

XSSによるクッキー情報漏えいの防止策の一つとして。あとで、Jeansにも導入する。

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

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

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

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

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

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

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

とりあえず、３つの対策を用意。

１）リモートコードインサーション対策
２）XSS対策
３）SQLインジェクション対策

何も考えずにコアの機能を利用することで、これらのセキュリティー対策が行えるようなツールを目指す。理想としては、意識せずにコードを書けば脆弱性はでず、何か特別なことを仕様としたときだけに脆弱性が出てしまうようなものにしたい。規約として、echo 命令はライブラリやプラグインでは使用禁止にするつもり。

<セキュリティー対策 のつづき>