カテゴリー
Computer Programming

session_regenerate_idの使い方に注意!

久しぶりにPHP-users MLを見るとsession_regenerate_id関数が「古いセッションIDに関連したセッション情報を削除しないのは困るよね」と投稿がありました。

バグレポートではBogus(バグじゃない)というステータスになっていました。確かにsession_regenerate_id関数は新しいセッションIDを生成する為の関数として追加されました。新しいセッションIDを作れば仕様上は問題ない、と主張できるかもしれません。しかし、アプリケーションの作り方によってはセキュリティ上の問題を発生させる原因になるので変更するべきですね。

セッションモジュール、セーブハンドラモジュール、シリアライザモジュールの各グローバル変数がマクロでアクセスされる作りになっています。(セッションモジュールは更にサブモジュールと持つ構造になっています。随分前ですがWeb+DB Pressに書いた通りです。興味のある方はどうぞ。)さらに引数などもマクロで定義されているため、初めて読むプログラマには非常に分かりづらいソースになっています。

PHPセッションモジュールのソースを読んだ事がある方なら分かりますが、グローバル変数を使用している、今回の場合はPSマクロで利用するグローバル変数、のでセッションID、PS(id)、を保存しないとならないように思えます。
# 今思いつきましたが、PS(data)にempty_stringを入れて
# おけばOKなような気がします。

session_destory関数にはバグがあるようでセッション情報は空になりますが、ファイルをunlinkしたいようなコードになっているのですが…、unlinkされていません。XFSなど、ディレクトリエントリにB-Treeを使用しているファイルシステムでは大量のファイルがあっても性能上や使用上問題ありません。個人的には50万ファイル(50万セッション)までファイル作成してベンチマークしてみましたが、性能は全く変わりませんでした。

ext3を利用している場合、2の問題で困る可能性があります。一つはinodeの枯渇ともう一つパフォーマンスの低下です。デフォルトではinodeが枯渇する可能性は大きいと思います。DoSの原因にもなるので注意しましょう。Linuxの場合、ディレクトリエントリはキャッシュされているので多数のファイルがある場合でもかなり良い性能ですが、それでも何十万ファイルレベルになると遅くなります。

セッション管理は有効期限を0に設定したセッションクッキー(ブラウザの終了と同時に削除されるクッキー)を利用し、自動再ログインなどの仕組みはアプリケーションでセキュリティ上の問題が許容される取り扱い方法を独自に実装する方が良い、と考えています。

もし有効期限が長いセッションIDを利用してログイン状態を保ち、セッションIDの再生成でXSSのリスクを軽減されている場合はsession_destroyを使用してセッションの削除を忘れないようにしなければなりません。ご注意ください。

カテゴリー
Computer

Senna 組み込み型全文検索エンジン

触ってもいませんが便利なようです。待っているとPHPのモジュールができると思う(違う?)ので待ってみることにします。

カテゴリー
Computer Other

自分用にAdsense!

仕事上、興味を持たなかったこと自体不適切(?)とも言えるかもしれませんが、アフィリエイト等に全く興味がありませんでした。新しく本を出版した際に、なんとなくAmazonのアソシエイト・プログラムはどの程度の利用されているか知りたくなり申し込み、このブログにも自分の書いた本のリンクを貼り付けています。

Web広告と言えばGoogleのAdsenseなのでAdsenseも申し込み、Wikiの方にはテキストリンクをページの一番下に貼り付けてみました。Amazonのアソシエイト・プログラムの時も使って見ないと分からなかったポイントカードとして利用方法がありましたが、Adsenseも同じでした。

Googleの広告は興味がある場合、時々クリックしていたのですが自分のWikiに貼り付けたテキスト広告はかなり的を得ています。Wikiのコンテンツはこれから拡充するレベルですが、ページに記載されている内容から関連する広告が表示されるので、クリックしてみたくなる広告が表示されます。Adsenseで儲ける事を目的とするのではなく、自分用のアンテナとしてAdsenseを利用する、と言う利用方法は良いのではないかと思いました。

趣味のページをお持ちの方でAdsense、アソシエイト・プログラムを自分用に付けるのは楽しみも増してお勧めと思います。

# そう簡単に儲かるものではありません。
# 儲ける事を目的にはじめてもがっかりするだけです。

カテゴリー
Computer Linux

Momonga Linux 2リリース

Momonga Linux 2が2005/4/27にリリースされました。

主なパッケージ

*kernel 2.6.10
*gcc 3.4.3
*glibc 2.3.4
*xorg-x11 6.8.2
*emacs 22.0.50
*firefox 1.0.3
*httpd 2.0.54
*mozilla 1.7.7
*OpenOffice.org 1.1.4
*openssh 4.0p1
*PHP 5.0.4
*postfix 2.2.1
*ruby 1.8.2
*samba 3.0.14a
*sylpheed 1.9.9

早々にPHP5が投入されています。
# 入れたのは私ですが。
# 最近何もできなくて申し訳ない > メンバーの方。

カテゴリー
Security

2ポートディスク?

この記事に書いてある「2ポートディスク」ですが、個人的にはあまり必要性が感じられませんが何か見落としているのでしょうか?

「2ポートディスク」とは2つのポート(I/F)を持つHDDの事だそうです。一つは読み込み専用、もう一つは書き込み専用だそうです。Linuxの場合、同じパーティションを何度でもマウントできます。例えばApacheは読み込み専用でマウントされたマウントポイントを利用し、コンテンツの編集者は読み書き可能にマウントされたマウントポイントを使用すれば良いように思えます。
# SELinuxにすれば、という話もありますが。

同じCPUに接続されているHDDが2つポートを持っていてもマウントオプションで読み込み専用と読み書きを使い分ける方法と違いがあまり無いので、共有ディスクにして、という話なのでしょうね。詳しい情報が書いてないのでメモとして。

カテゴリー
Computer Database

なぜMySQLなのだろう?

サイボウズが自社製品にMySQLを採用したそうです。MySQL ABとパートナー契約を結んだ、という事らしい。確かMySQLの商用ライセンスは250ユーロ程だったと思いますが、サイボウズもライセンス販売で商売しようという事なのでしょうか?

MySQLのコマーシャルライセンスのページにも書いてある通りサイボウズのケースは商用ライセンスが必要な事例にあたります。

MySQLのクライアント用のlibmysqlはオープンソースライセンスの場合、GPLライセンスであるためlibmysqlにリンクしているアプリケーションは完全ソースコードをGPLで公開しなければならない事になります。今までGPLとプロプライエタリなライセンスのデュアルライセンスのソフトウェアを開発してビジネスをするメリットを考えたことはありませんでした。「GPLはパックマン」と批判される関連製品のGPLライセンスによる完全なソースコード公開が必要な仕組みを利用して、自社製品をライセンス料を支払わずに利用している企業を見つけライセンス契約を結ぶと共にパートナーにし製品を販売する、というビジネスモデルは成り立ちますね。

まさかサイボウズがMySQLのライセンスがGPLであること、さらにGPLライセンスの内容をよく知らずに製品を開発して… と言う企業としては悲しい結末ということではなければと思いますが、どうなんでしょう?

# ヨーロッパではFirewall件がGPLライセンス違反で裁判になり
# 完全なソースを公開することで最近和解してましたね。
# PostgreSQLならBSDライセンスなのでこんな心配は無用ですが..

# 断っておきますが、私はPostgreSQLエバンジェリストです。
# しかし、アンチGPLライセンス派ではありませんし、
# 仕事ではMySQLも使っています。MySQLが特に嫌い、
# という事でもないです。

追記:
https://shop.mysql.com/?sub=vt&id=software
によるとトランザクション( InnoDB )をサポートするMySQLのライセンスは500ユーロ、InnoDBをサポートしない場合は250ユーロだそうです。

ITMediaの「GPLはパックマン」の記事ではBill Gates氏が何を批判していたか分からないですね。最近、php-devにlibnmzがGPLライセンスであるためモジュールをPHPに含めることができない、という問題が発覚しました。そのとき私が書いたメールにGPLと商用製品の問題について記述しています。

最近ではサンのJ・シュワルツ、オープンソースライセンスのGPLを批判にあるようにSUNの会長がGPLを批判してますね。

カテゴリー
Security

クロスサイトリクエストフォージェリ(CSRF)

クロスサイトリクエストフォージェリ(Cross-Site Request Forgeries – CSRF)の話。名前はともかくこれが新しい攻撃ではないことは高木さんも書かれている通り。誰でも思いつくセキュリティ上の不備ではないでしょうか? 私はもう何年も前からこういった事が起きないようライブラリ化しています。

HTTP Response Splitting Attackの時もHTTPヘッダに出力する値を確実にコントロールするのは当たり前。おかしなヘッダを送信させられるとキャッシュがおかしくなる事はまっとうなWebシステム開発者なら解っていて当たり前、と思っていたのですが…

セキュリティ関係の話をする時にはいつも言うことですが、「間違いを探すのではなく正しい事を確認するように」を実践していれば、なんだか訳の分からないセキュリティ用語が飛び出してきても慌てることは無いはずです。

参考:
http://d.hatena.ne.jp/hoshikuzu/20050130
いろいろリンクがあって参考になります。

追記:
入力済みの値の再検証を防ぐ方法(つまり期待したとおりの入力であること保障する方法)をいくつかのセミナーで説明したと思います。前のフォームに入力された値をメッセージダイジェストで確認していればCSRF問題は発生しません。フォーム毎にIDを発行し、再投稿を防ぐなど処理を行っていれば完璧です。