_ さて連休も今日で終わりか (02:20)

ただし俺の連休はまだ続きそうだ。っつーのは、下の子供が水疱瘡にかかったため。現在ぶつぶつ怪人状態。一週間くらいは通園禁止だろうから、今週は半分くらいオクサンと手分けして休まないとならないんだろうなー。俺自身もずっと喉と鼻と頭に来る風邪を引いていて（どうやら花粉症ではないらしい）結構きつい。

ちなみにこの連休中は久しぶりにほとんどPCに触らなかった。閲覧系はそれなりにしているけれども、生産的なことはほとんど何もしていない。で、久しぶりに昨日あたりからぼつぼつ復帰準備をしているんだけど、いまいち気分が乗らないなー。引っ越しの準備もそろそろはじめないとまずいんだけどなー。

_ HTML_QuickFormのRangeルールで (02:57)

マルチバイト文字を含むテキストの文字数チェックをclientとserverで統一感がある形で実行したい場合は、HTML/QuickForm/Rule/Range.phpを

- $length = strlen($value);
+ $length = mb_strlen($value);

に書き換えちゃうのが一番いいのかなー。でもそれだとpear upgradeしたときに面倒なことになりかねないから、上記のような書き換えを行ったHTML_QuickForm_Rule_RangeJPクラスを別途用意しておいて、あらかじめ、

$rangejp =& new HTML_QuickForm_Rule_RangeJP();
$rr =& HTML_QuickForm_RuleRegistry::singleton();
$rr->registerRule('range', NULL, $rangejp);
$rr->registerRule('minlength', NULL, $rangejp);
$rr->registerRule('maxlength', NULL, $rangejp);

とかrange関係のルールを上書きして使った方がいいのかなー。ひとまず後者にしてみたけど、いまいち美しくない気もする。あと、これだと最終的にバイト数でチェックをしたい場合に、もう一段階ruleをかまさないとならなくなるのがじゃまくさい。

この辺の扱いをきれいにまとめる方法ってないかなー。結局、javascriptで文字列のバイト数チェックを行う関数を書いてそれを使うようにするか、あるいはマルチバイトでサイズチェックを行いたい場合は基本的にclientチェックは使うな、ってことになっちゃうのかな。

_ キーワードとタグ (11:16)

「はてなブックマークとTaggingはてなブックマークとTagging」あたりのネタ。ちゃんと一般論としてまとめる気力がないんで、現在のMM/Memoの実装例を紹介してみる。

MM/Memoでは、

• ユーザーが自由に入力するタグ（ジャンル）
  • タグ入力候補として、該当のドキュメントから自動抽出した特徴語を表示し、ワンクリックでタグとして追加可能な入力補助機能
• 上記で自動抽出した特徴語を、隠しタグとして登録。通常表示時は見えないが検索キーとしては利用できる。
  • 検索から「自動ジャンルも検索」を有効にして検索すると、ユーザーが入力したタグと、自動登録した隠しタグをフラットに検索する

というようにしてある。

現状のインターフェースが使いやすいかどうかはともかくとして、ひとまず上記のような構造にすれば、ちゃんとタグを入力したい人はdel.ico.usみたいな使い勝手、タグを入力しない場合でもはてなブックマークみたいな使い勝手での、ブックマーク（メモ）の串刺し検索が実現できる。

あと、MM/Memoではブックマークのタイトル、タグ、コメントなどで使われているテキスト自体から特徴語を抽出し、特徴語が類似しているブックマークをEstraierの類似文書検索機能を利用して抽出している。だから、似たような話題に関するブックマークは、URLやタグが違っていても、related検索（各ブックマークの虫眼鏡マークをクリック）である程度抽出することができる。

MM/Memoは実験的に機能を追加していっているんで、インターフェースはあまり洗練されていないし、作ってみたらダメだった機能もいろいろあるけれども、上記のような機能群はかなり有用な機能だと思う。洗練されたインターフェースで実用レベルで実装してくれるところ希望。

_ メモを該当ページ上で書くbookmarklet (21:18)

「JavaScriptの動的ロード」話をみて最初に思いついたネタなんだけど、どうせ誰か作るだろうと思って放置していたら誰も作る気配がないんで、試しに作ってみた。

bookmarklet: その場でMemo!

何をするものかというと、MM/Memoにメモを登録するフォームを、現在開いているページ上の可動レイヤーとして生成し、ドキュメントを見ながら入力して投稿できるというもの。呼び出しているのは、このスクリプトね。

あまり真面目に作ってないけど、フォームの見た目を格好良くして、レイヤーの移動周りの処理ももうちょっとインターフェース的にわかりやすくしたら、仕組み的にはかなり使えると思う。一応WindowsのIE、Firefox、Opera8では動作した。

「隠す」をクリックするとフォームが消えるけど、もう一回同じbookmarkletを実行すれば、消えた前の状態でフォームが復元する。フォームを移動しても邪魔になる場合なんかに、一時的にフォームを消して、その下に隠れている文章を読んだりするのに使う。

呼び出しているjavascriptをダウンロードして、フォーム生成部分を適当に書き換えて使ったら、他のいろんなサービスにも使えるでしょう。blogツールに直接投稿できるようにしたりしてもいいかもしれない。wemaと連動させてもいいかもね。ユーザーサイドjavascriptなんかと組み合わせれば、どこでもwemaみたいなこともできそうだ。

JavaScriptコードが消えちゃった

サーバートラブルの影響で、上記JavaScriptコードが消えちゃった。もう一回書く気になれないんで概要だけ書いておくと、bookmarkletから外部JavaScriptコードをインポートして、そこで適当な可動レイヤーを作った上に投稿フォームを生成する、というコード。bookmarkletの文字数制限を回避するために、外部JavaScriptコードを呼び出す方法は、malaさんのところとかで詳しく説明されている。可動レイヤーとかフォームの生成は、JavaScript＋HTMLの基本なんでまあ適当に作ってください。

_ 刺さってた？ (01:22)

httpdのプロセスがおちているわけでもないし、実際ぽつりぽつりとアクセスは受け付けていたみたいなんだけど、なぜかほとんどhttpdが応答しない状態になっていた模様。apachectl gracefulでは復帰しなかったけど、stop→startで復帰した。これはいったいなんだったんだろう？　CPUもネットワークも特にいつもよりも高負荷になっていたわけではないみたいだし、ログにも特に変わった痕跡はなさげなんだけどなー。

_ なぜ多言語対応しないのか (11:31)

「多国語で書けるブログはどこ？ブログ124サービス【文字コード】全チェック」あたりのネタへの反応。

非プログラマの人がわかりやすいようなたとえにすると、「文章を書くときには、多言語でそのまま（逐次）翻訳できるような文章を書け。しかも最低でも英語版も用意しておけ」と言われるような感じかなー。

と思った。

_ バンパーを落として逃げた車 (12:51)

昨日の夜うちの近所の交差点で事故があった。ブレーキ音と衝突音がして見に行ったところ、バンが1台反対車線側に停まっていて、その車体の下に何かが挟まっている。「人？　バイク？」と思いながら近づいていったら、車の前のバンパー（ナンバー付き）だった。集まっている人の話を漏れ聞いたところによると、ぶつかったもう1台の方の車は逃げだし、その落とし物がそのバンパーだそうな。盗難車とかじゃない限りは簡単に捕まっちゃうね。それとも盗難車だったりするのかな？

_ 一応治癒証明は出た (12:51)

下の子供の水疱瘡、一応今日病院で治癒証明をもらってきた。でもまだ顔がぶつぶつだよ。もうかさぶたになっているから、うつることはないのかもしれないけど、保育園の他の子供の親とかいやな感じだろうなー。といっても、もともとこの水疱瘡は保育園でもらってきた（3週間くらい前に流行った。水疱瘡の潜伏期間は2週間くらいらしいんで、ちょうど日数があうね）ものだけどな。

_ xpdfで日本語 (19:08)

FC3でaptでインストールしたxpdfで日本語が通らない。xpdf-japanese相当のものは入っているし、/etc/xpdfrcにもちゃんと

include /usr/share/xpdf/japanese/add-to-xpdfrc

はあるのに。しょうがないから~/.xpdfrcに/usr/share/xpdf/japanese/add-to-xpdfrcの内容をコピーして動かしているけど、釈然としない。/etc/xpdfrcが見えていないのかな？

_ おや？ (13:52)

今日のmm_footerの内容がなぜか文字化けしているな。SHIFT_JISで表示されているらしい。元のRSSもtDiaryもEUC-JPなのに、なんでSHIFT_JISなんかになったんだ？　rss-recentって文字コード自動識別変換とかしているんだっけ？

キャッシュ消したら治った

内容は変わっていないのに、自動識別結果が変わった？

_ ウェブログの心理学(山下 清美/川上 善郎/川浦 康至/三浦 麻子) (14:38)

いかんいかん、感想を書かないでいたら『教科書には載らないニッポンのインターネットの歴史教科書(ばるぼら)』が届いちゃったよ。こっちをちゃんと読む前に『ウェブログの心理学』の感想を書いておこう。

この本は、Web（インターネット）で個人的な文章を継続して発表すること（ウェブログ/Web日記/個人サイトなど。以降ウェブログという言葉で代表させる）に関するさまざまな知識や情報をまとめたものだ。

内容としては、

• Webを使ったコミュニケーションの特徴
• 日本における歴史、ツールやサービス、コミュニティの紹介
• ウェブログの分類
• ウェブログを書くということ・人の分析
• 従来そして今後の課題
• Web日記/ウェブログを続けるに当たってのさまざまなアドバイス

などが網羅されている。

実際長年にわたってウェブログを書いてきた筆者たちが、その経験と社会心理学者という学問的知識を背景にまとめたこれらの文章は、ウェブログ作者のためのケーススタディとして活用することができる。

すでにある程度の期間ウェブログを続けてきた人は、その中のいくつかの知見をすでに手に入れていることだろう。また、自分の中で漠然とまとめきれずにいた知見が、この本によって改めて明確化（文章化）されるといったことも多いだろう。まだウェブログの経験が浅い人も、この本を読んでおくことでためになる点が多いはずだ。歴史は繰り返されており、先人が経験によって培ったノウハウは、現在でも十分に役に立つことが多いからだ。

たとえば、p17で紹介されている、さまざまなウェブログを自己表現の方法と情報の種類で分類した以下のマトリックスなどは、自己および他者のウェブログを分析する際には非常に参考になるだろう。

歴史資料としての意義は、『教科書に載らないニッポンのインターネットの歴史教科書』の圧倒的な情報量には劣るが、『教科書に〜』は歴史的な事実の詳細な記録という形式で記述されており、たいていの人はその圧倒的な情報量を咀嚼しきれないだろう。ウェブログに特化した歴史の概要を追いたい場合は『ウェブログの心理学』の方が便利だろう。

で、ここからは余談。

『ウェブログの心理学』は比較的細かいところに気を配ったアドバイスが書かれているけれども、あくまでも「表通りの歩き方」的な話にとどまっている。で、『教科書に〜』をぱらぱらっとめくった感触では、こっちはかなり裏通りの話まで書かれているみたいだけど、基本的に「事実の記録」を重視している感じで、『ウェブログの心理学』みたいなアドバイス的な部分は含まれていなさそう。

というわけで、誰か「裏通りの歩き方」的なアドバイス本を書いてみると、スキマが埋まっていいかもしれない、とか思った。具体的には、「フレームにならない議論のやり方」「2chで晒されたときの対処法」とか。あるいは「ネットバトル（フレーム合戦）のやり方」もあった方がいいかもしれない。小倉弁護士的あたりに「コメントスクラムへの対処法」とか寄稿してもらいつつ（笑）。

なんか

読み返してみると、まるで『ウェブログの心理学』がハウトゥ本のような書き方になっているな。『ウェブログの心理学』で得られるのは、いわゆるハウトゥ本的な知見ではなく、メタウェブログ（ウェブログを書くということに関してのメタな思索）的な知見なのですよ。とフォローしておこう。

_ 俺が作っているもの・ここに書いているネタは (11:05)

自分が使いたいから作ったもの（だから俺が使いやすければそれでよくで、あまり一般向けに作り込まない）と、この技術をこういう風に使うとこういうことができますよ（誰かそれを応用してもっと楽しげなものを作ってね）というものがほとんどなんで、ぱくりフリーですよ。公開しているコードなんかも、俺以外の人の権利を侵害するものでなければ、自由に使っていいですよ。

と一応書いておこう。

_ MTの認証Cookieに関する脆弱性とされているものについて (02:38)

「【重要】 第三者による不正アクセスを許す危険性の対策について」で発表された内容について、「Movable Type の脆弱性の件 : NDO::Weblog」のコメント欄あたりでごちゃごちゃ書いていたことをまとめておこう。

今回の問題は結局、

• movable typeのWeb管理ツールでは、認証Cookieとして「ユーザーID」と「パスワードのハッシュ」を組み合わせた文字列を使っている
• その認証CookieはそのままAtom APIを使った外部ツールからの認証処理でも使われている
• もしも認証Cookieが漏れた場合、Web管理ツールやAtom APIインターフェースを通して、管理機能（の一部）を乗っ取られる可能性がある（追加情報：BlogWrite担当さんのコメント）

ということだと理解した。

もしも他に問題があるならば話は変わるが、今回の発表の元になった脆弱性報告を行った人の「「旅行びと日記」日記: Movable Type 3.151以前のセッションハイジャック脆弱性問題」による解説と、JVNによる発表「JVN#74012178 Movable Type におけるセッション管理の脆弱性」およびIPAによる発表「JVN#74012178：Movable Type におけるセッション管理の脆弱性」をあわせてみると、結局それ以上の問題はないように見える。

これは、「漏れてはまずいから漏れないようにしている認証情報（Cookie）が、もしも万が一漏れたら危険なことになりますよ」という話だ。しかし、具体的に「もしも万が一」を突破する手段がない限りは、別に危険ではない。あらゆる認証情報（たとえばパスワードとか）は、「もしも万が一」漏れたら危険なものだ。しかし「万が一漏れたら」というだけでは、ふつう脆弱性とは言わない。具体的に漏れる方法が見つかった段階で「脆弱性」になる。

「あなたのメールパスワードは、他人に漏れないように注意してくださいね。もしも漏れたら他人にメールを読まれちゃいますよ」というだけで、脆弱性とは言わないだろう。具体的にパスワードが漏れる手段が見つかった段階で、それは脆弱性となる。

確かにmovable typeの、認証Cookieがそのまま「無期限に」「複数の認証に」利用できるという設計は、セキュリティ的に安全性が高いとは言えない。しかしそれは「脆弱性」ではなく、「よりセキュリティ的に安全性が高い設計に変更することが望ましい」程度の問題だろう。

脆弱性報告を行った人は、その根拠となる参考文献として高木浩光氏による「安全なWebアプリ開発 31箇条の鉄則（PDF）」を挙げているようだが、その中の「14.セッションIDを使う」において高木氏は、「ユーザIDだけを引数とする方式」については、「致命的な欠陥、認証なしと同等、ファイル丸見え並の危険性」としているが、今回movable typeが採用していた「ユーザID＋パスワードのハッシュ値を引数とする方式」については、「これでもよいが、セッションを使う方式の方がより安全」としている。つまり、この方法でも問題はないわけだ。

ここからは邪推。

上記のような報告を受け、JPCERT/CCもしくはIPAからシックスアパートに対して勧告が行われた。が、上記のような判断を行うとこれは「脆弱性」とは言えない。しかし、シックスアパートの担当者は、そのことをJPCERT/CCもしくはIPAの担当者に理解してもらうことができなかった。あるいはJPCERT/CCもしくはIPAの担当者はそのことを理解できなかった。公表と対処を迫られたシックスアパートは、納得がいかないままに情報を公開した。しかし、納得できていないので、ひとまずポイントとなるキーワードはちりばめたものの、非常に微妙な表現の文章になってしまった。という経緯なのではなかろうか。

というわけで、私はこの件は脆弱性ではないと思います。ただし、認証Cookieの仕様はもうちょっと安全性の高いものに変えた方がいいとも思います。おしまい。

ちょっと修正

• 「ユーザ＋パスワードのハッシュ値を引数とする方式」→「ユーザID＋パスワードのハッシュ値を引数とする方式」
• 「JNAもしくはIPA」→「JPCERT/CCもしくはIPA」。っつーかJNAってなによ。
• 「Web管理ツールやAtom APIインターフェースを通して、管理機能を乗っ取られる可能性がある」→「Web管理ツールやAtom APIインターフェースを通して、管理機能（の一部）を乗っ取られる可能性がある」

_ Re:「ここギコ！: MovableType脆弱性の話」 (16:49)

個人的には（そこまで重大かどうかは別として。緊急度は「低」だと思う）やっぱりこれは脆弱性といってよいのでは、と思います。

まあそう考える人もいるでしょう。元報告者の方およびその報告を受けて対応した方々はそう考えているんでしょうし（でもシックスアパート自体は「脆弱性」ではなく「危険性」と書いているんですけどね。その辺の言葉の選択もビミョー）。

ただ、Webアプリケーションで認証状態を維持する方法としては、一般的にCookieが利用されるものです。そのCookieにどのような情報が含まれるのであれ、そのCookieが漏れた場合は、ある程度の期間において認証状態が乗っ取られる可能性が発生することになります。

そのCookieによる認証をどの程度の期間有効にするかはWebアプリケーションの設計によりますが、ブラウザセッション（ブラウザを閉じるまで）を越えて有効な認証状態を継続するようなアプリケーション（MTでいうところの「情報を登録する?」オプションがあるもの）では、無期限とまでは言わないまでもかなりの期間、認証が有効な状態が継続するでしょう。

そして現在のところ、WebアプリケーションでHTTPセッション（1回のサーバーへのアクセス）を越えて状態を維持する手段としては、機能性・利便性・安全性のバランスにおいてCookieよりも妥当な方法がありません。より安全なSSL＋secure Cookieを利用する方法や、証明書やハードウェアキーなどを利用した方法は、現時点ではいつでも使える手段とはなっていません（もちろんより安全性が必要な場合は、それらを選択するべきでしょうけど）。

つまり、現在一般的なWebアプリケーションで（特にブラウザセッションを越えて）認証状態を継続しようとした場合は、多かれ少なかれ今回movable typeの認証Cookieが持っていたような危険性を持たざるをえないわけです。で、Webアプリケーション側では、漏れたら危険な認証情報をCookieに持たせる代わりに、Cookieが第三者に漏れないようなアプリケーションの設計にするわけです。Cookieが漏れないようにする（入り口に鍵をかける）ことによって、安全性を確保するわけですね。

もちろんCookieがそれほど安全なものでないことは、XSSやブラウザ自体が持つ脆弱性、盗聴の危険性などから、ある程度知られています。そして、そのような危険性への回避策もいろいろとあります。ただし安全性を高める回避策は基本的にはSSLとの組み合わせとなってしまう（利便性が損なわれすぎる）ため、一般向けのアプリケーションではそれに依存した設計はできません。

というわけで、現在のところ「Cookieにはある程度秘密の情報を保存してもいいが、その代わり第三者にCookieが漏れないような設計にする（漏れた場合はそれは脆弱性である）」というWebアプリケーションの設計方針は、（それほど重要ではない情報・機能を扱うWebアプリケーションにおいては）妥当なものだと考えています。おそらく現在稼働しているWebアプリケーションで、そのような設計方針の下に作成されたものは非常に多いのではないでしょうか。

で、私はmovable typeにおいても、基本的には（扱っている情報・機能とのバランスを考えて）上記のような設計は「あり」だと思います。つまり、「Cookieが漏れるような穴がない限りは、Cookieに秘密情報を保存していること自体は問題にならない」という考えです。ただし、より安全性を重視した設計にするならば、Cookieに保存する情報の内容自体ももっと安全な（漏れたときの影響が小さい）ものにするべきだとも思いますけど。

movable typeのような使われ方をしているWebアプリケーションでは、SSL必須にするわけにはいかないでしょうから、今回の問題を解決する方法としては、おそらくランダム性の高い（少なくともAtom APIでは使えない）認証キーをCookieに保存するようにするのでしょう。それでも「情報を登録する?」オプションが存在する限りは、その認証キーはある程度の期間有効でしょうし、その認証キーが漏れた場合はWeb管理ツールを乗っ取られる危険性があります。Cookieに登録されている情報の内容に関わらず、「Cookieが漏れたら危険である」わけです。つまり重要なのは「Cookieが漏れるかどうか」であって「Cookieに記録されている情報」の方ではない、と考えるわけです。

と、なんか長々書いてきたけど、うまい締めが思いつかないんで、ひとまず「まあそういうことなんですよ」って感じで終わっておく。それにしても俺は別に「MTスキー」でも「セキュリティスキー」でもないのに、なんでこんなに一生懸命説明しているんだろうなー。

_ 「「MT に脆弱性」@水無月ばけらのえび日記」より (21:19)

非 SSL で Basic 認証を使っていれば普通に起きていることなので、大して危険ではないような気もするのですが、危険性の評価は利用状況によるでしょう。MT を利用してるのは個人サイトだけではありませんし。

ってあたりがポイントなのかな。確か、商用サービスとか企業向けサービスとかで、MTをより機密度が高い情報サービスと連携させて動くように組み込んでいる事例とかもあった気がするし、そういうマキシマムの危険性を重視した上で「脆弱性」として扱うというのは、ありといえばありかもしれない。

ただ一般ユーザーレベルで取り扱う情報を管理するツールとしては、これを「脆弱性」扱いするのはなんか違うと思う。たとえば（SSLなしで）BASIC認証で管理機能を保護しているCGIなんかは、すべてこれと同じような危険性をはらんでいる（Cookie系のアタックに弱い点を考えると「同じような」というのは言い過ぎか）ことになるわけだから、これが「脆弱性」ならばそれらも「脆弱性」になっちゃうってことだし。

_ 昨日の件の続き (11:46)

「Marklet BLOG: 脆弱性とセキュリティホール」にある、

例えば、ID、パスワードを入力して認証するシステムでは、その２つキーを盗み出したり、推測したり、総当たりで試す事によって突破できる可能性があるため、「脆弱性を抱えている」と言えます。

一般に「脆弱性がある」といった場合、保護しようとする情報の重要度に見合わないレベルの脆弱性が認められた場合に使われるのではないでしょうか？

ってあたりから考慮すると、

企業ユーザー・商用サービス等、秘匿度の高い情報を取り扱っている場合

脆弱性である。ただし、緊急度低・危険度低。パッチが出るまでの対処法として、SSLの利用、管理機能の利用後は必ずログアウトする、「情報を登録する?」オプションは使用しない、という運用を推奨。

一般個人ユーザー等、秘匿度の低い情報を取り扱っている場合

脆弱性というレベルではない。パッチが出るまで通常の使用を続けても問題ない。

ってあたりが妥当なんじゃないかなーと思う。

_ IPAに問い合わせをしてみた (13:20)

IPA Webサイトにおきまして、

・JVN#74012178：Movable Type におけるセッション管理の脆弱性 - http://www.ipa.go.jp/security/vuln/documents/2005/JVN_74012178_MovableType.html

として公開されております脆弱性問題について、Webアプリケーション開発者の立場としては、上記ページの図に書かれている2番目のステップ「悪意あるユーザーにセッション情報を盗み取られる」を実現するための具体的な手段（欠陥）が存在しない限り、それは「脆弱性」として扱うべきではないのではないかと考えております。

というのは、「悪意あるユーザーにセッション情報を盗み取られる」ステップの具体的手段を考慮しなかった場合、現在標準的なWeb関連技術で作成されているWebアプリケーションの大多数が「もしもセッション情報を盗み取られたら」「不正アクセスされてしまう」に該当してしまい、それらは「脆弱性」を持つということになってしまうからです。

もしよろしければ、この件が「脆弱性」として扱われることになった詳しい経緯をお聞かせ願えませんでしょうか。また、もしご回答をいただける場合は、その内容を私のWebサイトで公開する許可をいただけないでしょうか。

この件に関しては、私のWebサイト（http://tdiary.ishinao.net/20050514.html）において、より詳しい思考の過程を書いておりますので、もしよろしければ参考情報としてご覧ください。

以上、よろしくお願いします。

想定する（というか納得できそうな）回答例としては

• 「セッション情報が盗まれたら不正アクセスされる」が問題なのではなく、セッション情報として「無期限に」「他の認証でも利用可能な」情報が使われていたことが問題である。→そのポイントを明確にする文書にして欲しい
• MTが企業系情報サービスなどにも組み込まれており、それらの事例においてはこの仕様が重大な問題を引き起こす可能性があるため。→その辺のニュアンスを文書に盛り込んで欲しいなー

といった感じかなー。

_ 認証の維持とセッション管理の違い (09:11)

「認証の維持」といわゆる「セッション管理」とはちょっと違う。

一般的なユーザー認証では、サーバー側にIDとパスワード（のハッシュ）という情報を持ち、ユーザーがフォームから入力したIDとパスワードの組み合わせを、サーバーの持つ情報と照合することによって認証処理を行う。

ただし、毎回フォームでIDとパスワードを入力するのは面倒なんで、一度入力したIDとパスワードは、2回目以降いちいち入力せずに認証処理を行いたい。要するに一度入力されたIDとパスワードを覚えておいて使い回したい。

BASIC認証とかのブラウザが対応している認証方式の場合は、ブラウザの機能として覚えてくれる。そして、アクセスのたびにIDとパスワード（のBASE64エンコード）が送られ、毎回認証処理が行われる。ちなみにBASIC認証で送られるパスワードのBASE64エンコードは可逆なので、パスワードを平文で送っているのと大して変わらない。

ブラウザの標準機能を使わず認証を行う場合は、Webの標準的な機能を使ってIDとパスワードを覚えておかないといけない。そこでCookieが使われることになる。IDとパスワード（平文あるいはBASE64のような可逆エンコード）を覚えておくというのが一番単純なやり方（初回にフォームからIDとパスワードが送られたときと同じ照合コードが使える）だけど、ちょっと安全性を高めたければ、IDとパスワードのハッシュ（非可逆）を覚えておく。

サーバーサイドには、IDとパスワード（のハッシュ）の組み合わせしか認証チェック用の情報を持たないことが前提なんで、ブラウザから送られる情報は、サーバーに保存されているIDとパスワード（のハッシュ）を使って照合可能なデータである必要がある。

一方（いわゆる）セッション管理というのは、基本的には認証とは関係なく、単にあるブラウザからの連続したアクセスを同定し、複数回のアクセスにおいて状態（データ）をサーバー上で保持（認識）したい、という話だ。

そのためには、あるブラウザからのアクセスを特定するために、ブラウザごとにユニークな識別IDを割り振り、それを使用する。それがセッションID。そのセッションIDも基本的にはCookieに保存することになる。

セッションIDはユニークであれば連番とかで生成してもいいけど、連番で生成したセッションIDの場合、他の人のセッションIDが類推できてしまう。たとえば自分のセッションIDが100だったら、「きっと99とか101とかの人もいるに違いない」とか。だから、セッションIDはできるだけ類推の効かない（ランダム性の高い）ものを使うことで、安全性を高める必要がある。

セッション管理を使えばあらゆる状態を維持することができるんで、もちろん認証の維持にも使うことができる。セッション管理の仕組みを認証の維持に使うことによって、IDやパスワードと直接結びつくデータを毎回送信する必要がなくなり、安全性が高まる。

またいわゆるセッション管理機能を使わない場合でも、直接IDやパスワードと結びつかないランダムでユニークな認証キーをサーバー側で生成し、サーバー上でIDと結びつけておくと同時に、ブラウザにその認証キーを覚えてもらう。そして、その認証キーを利用して認証処理を行うことによって、直接IDやパスワードに結びつく情報のやりとりを最小限に抑えることにより、安全性を高めることができる（他にも方法はいろいろある）。

ただし、セッションIDやランダムな認証キーを利用する場合でも、直接IDやパスワードと結びつくデータが流れないというだけで、セッションIDやランダムな認証キー自体が直接認証機能と結びつき、それを悪用されることで認証処理を乗っ取られることに代わりはない。

また、せっかくセッションIDやランダムな認証キーを利用していても、その有効期間が必要以上に長い場合は、結局その文字列自体をパスワードのように利用することができ、セッションIDやランダムな認証キーを使っているからより安全だ、とは言い切れない。もちろんCookieが漏れるような設計だったら、セッションIDやランダムな認証キーを利用していても意味がない。

って俺は毎日なんでこんな文章を書いているんだろうなー。

ところで、JavaScript必須でチャレンジ＆レスポンスとかやっている例ってあるのかな？とふと思った。

_ IPAから返事が来た (16:05)

昨日の問い合わせの返事が来た。なかなか早いなー。すげー時間がかかるかと思ったのに。ちなみに内容は以下の通り（公開許可取得済み）。

IPA セキュリティセンターです。

お問合せいただきました件ですが、脆弱性関連情報の個々の取扱いの詳細に関するご質問につきましては、回答を控えさせていただいておりますので、ご了承下さい。

本件が脆弱性であるかどうかの判断は、2004年7月7日に経済産業省より公示された「ソフトウエア等脆弱性関連情報取扱基準」（平成16年経済産業省告示第235 号）および、「情報セキュリティ早期警戒パートナーシップガイドライン」に基づき行ないました。

詳しくは IPA ウェブサイトの「脆弱性関連情報の取扱い」より、それぞれの資料をご覧下さい。

http://www.ipa.go.jp/security/vuln/

以上、よろしくお願いいたします。

ということで、個々の取り扱いの詳細については答えてもらえないそうだ。まあ確かに細かい問い合わせにいちいち答えてられないだろうしなー。詳細に答えてもらいたければ、聞く方もそれなりの手続きをふまなきゃだめなんだろう。

で、返答のメールに書かれていた「ソフトウエア等脆弱性関連情報取扱基準（PDF）」および「情報セキュリティ早期警戒パートナーシップガイドライン（PDF）」を読んでみる。

「脆弱性」の定義は、前者では、

ソフトウエア等において、コンピュータウイルス、コンピュータ不正アクセス等の攻撃によりその機能や性能を損なう原因となり得る安全性上の問題箇所。ウェブアプリケーションにあっては、ウェブサイト運営者がアクセス制御機能により保護すべき情報等に誰もがアクセスできるような、安全性が欠如している状態を含む。

後者では、

脆弱性とは、ソフトウエア製品やウェブアプリケーション等において、コンピュータ不正アクセスやコンピュータウイルス等の攻撃により、その機能や性能を損なう原因となり得るセキュリティ上の問題箇所です。

なお、ウェブアプリケーションにおいて、ウェブサイト運営者の不適切な運用によって、個人情報等が適切なアクセス制御の下に管理されておらずセキュリティが維持できなくなっている状態も含みます。（ウェブサイトの不適切な運用に関しては付録４に示します。）

となっていた。

「攻撃によりその機能や性能を損なう原因となり得る安全性上の問題箇所」の解釈がポイントなんだろうな。俺は「具体的な攻撃手段」が存在した上での「安全性上の問題箇所」が「脆弱性である」と考えるんだけど、ポイントを「安全性上の問題箇所」にある（具体的な攻撃手段はどうでもいい）と読む人もいるんだろうな。

個人的にはすごく納得がいかないんだけど、これ以上追求するのは大変そうなんで、ここまで調べた段階でしばらく様子を見ることにしよう。

様子を見るといいながら

やっぱり気になったんで、もう1回だけIPAに聞いてみることにした。内容は

「具体的な攻撃手段」が存在しない場合でも、「セキュリティ上の問題箇所」が存在すれば、「脆弱性」であると解釈されるのでしょうか？

といった感じ。

粘着ですまんのー＞IPAの担当者の方。でも今後の開発指針とかにいろいろ影響が出るんで、つっこんで聞いておきたいところなんだよなー。

っつーかぶっちゃけ、HTTPで認証をやっているありとあらゆるものは、すべて脆弱性だっていう判断だって、全然おかしくないわけよ。というか、現状のインターネットははっきり言ってゆるゆるのがばがばなわけだよ。だから、ヒジョーにキビシク脆弱性認定を行うことで、「痛みを伴う改革を断行しよう」とか言われたら、それはそれで納得できるわけよ。で、その辺どうなの？

_ だいぶ軽くなったかな (13:42)

• Apacheのモジュール一覧を見直し、だいぶいらないモジュールを削減した（静的組み込みにはしてないけど）→気休め程度
• 重い検索（テーブルロックがかかるやつ）専用MySQLプロセスを別に立てていたのをやめ、MySQLプロセスを1個にした→やっぱこれが重かったよね
• その代わり、slow_logから抜き出した重い検索処理は、実行前にexplainでその重さを（簡単に言うと各検索条件ごとのrowsの多さ）をチェックし、ある程度以上重い検索と予想される場合は、実行をキャンセルするようにした→これで1プロセスですべての検索を処理しても、テーブルロックされる時間が短くなった
• httpdのログをweeklyでローテートしていたんだけど、その日本語検索キーワード解析処理とかがめちゃめちゃ重かったんで、httpdのログはdailyでローテートするようにした→これは定期的にスラッシング気味になる原因だったっぽい
• MySQL、Apacheのパラメータを状況に合わせて微調整→そんなに意味はない

って感じ。

_ 追加質問に対する答え (17:54)

追加で質問したメールに対する答えが来た（公開許可取得済み）。

IPA セキュリティセンターです。

お問合せいただきました件ですが、具体的な攻撃手段の有無による脆弱性判断については、個々の事例毎に判断しております。

また、脆弱性関連情報の届出に関するお問い合わせは、以下のメールアドレスで承りますので、今後は、こちらまでお願いいたします。

脆弱性関連情報の届出に関するお問い合わせ窓口

vuln-inq@ipa.go.jp

以上、よろしくお願いいたします。

ということで、要は場合によっては「具体的な攻撃手段」が存在しない場合も「脆弱性」と判断する場合がある、ってことですね。そのポリシー自体はまっとうだ。具体的な攻撃手段が存在しなくても、総合的な危険度が高い危険性ってのは存在しうるし。で、今回のMTの件は、「具体的な攻撃手段」が存在しなくても「脆弱性」と判断するレベルだと、総合的に判断されたってことになるんだろう。

さらに粘着質問するならば、

• IDとパスワードのハッシュを長期間（10年間）有効な認証Cookieとして保存する

だけでも「脆弱性」となってしまうのか、それとも

• そのIDとパスワード（のハッシュ）が他の認証付きインターフェース（Atom APIなど）でそのまま利用できる

との組み合わせが同時に成立した場合のみ「脆弱性」と認定されるのか、とか聞いてみたい気もするけど、単なる技術上の仮定条件だけでは、また「個々の事例ごとに判断している」という答えになっちゃうんだろう。

というわけで、今回のMTの件が「脆弱性」と判断された具体的なポイントはよくわからなかったけれども、ひとまず自分が関係するWebアプリケーションが「脆弱性」認定されてしまわないように、思い当たるふしがある方々は早めに対処しておいた方がいいでしょう。

もしさらにつっこんで聞いてみたい人がいた場合は、上記引用部にあるメールアドレスがその手の受付窓口らしいんで、そちらに問い合わせてみるといいんじゃないでしょうか。結構レスポンスがいいんで、聞いてみる価値はありそうです。

_ テーマをオリジナルに変えてみた (15:43)

といっても、digital_gadgetsの写真を差し替えて、高さと色をちょっとだけいじっただけだけど。tDiaryテーマは確かにそこそこ以上のクオリティのものをとっかえひっかえ使えるって意味では便利だけど、そのせいでサイトの（見た目上の）アイデンティティが薄れるというデメリットもあったりするんで、ある程度ちゃんと使おうとした場合は、好きなtDiaryテーマを選んで、それにちょっとだけ独自の色を付けて、オリジナルのテーマとして長いスパンで使った方がいいのかも。tDiaryのテーマに手軽にちょっとだけオリジナル色を出すための手段とかを提供したりすると、そういう使い方をする人も増えるかな。

_ テーマカスタマイザー (11:28)

昨日の思いつきネタをもうちょっと考えてみる。

基本的には、digital_gadgetsみたいな差し替えやすい背景画像を使ったテーマをベースにして、色味を合わせた好きな画像に変更しやすくしてやるというアプローチ。CSSの解釈順序を考えると、単にそのテーマを選択した状態で、HTML側に記述するCSSで背景画像指定を上書きしてやればそれで済みそう。

背景画像が一番オリジナリティを出しやすいポイントになるが、文字色、背景色等のパターンとして、ベースとなるテーマの色味に対して「ちょっと明るく」「そのまま」「ちょっと暗く」等を指定できるようにしてやると、さらにカスタマイズが効くようになる。こちらも、HTML側でCSS定義を上書きしてやればそれでいいだろう。

あとは、現在選択されているテーマを解析し、背景画像が使われているかどうか、調整可能な要素の色指定要素、などを抜き出して、それらを差し替えるためのインターフェースを用意してやればいい。

って実はすでにそういうのあったりして。

_ ファイルダウンロード処理時のIEの仕様に関する注意点 (13:55)

昔どこかのWikiに関連ログがあったはずだけど、ググってみても見つからないんで、念のためここでまとめておこう。Wikiに添付ファイル絡みの脆弱性が発見された絡みの情報として。

IEはセキュリティ設定の「拡張子ではなく、内容によってファイルを開くこと」を無効にしておかないと（デフォルトでは有効）、content-typeや拡張子よりもファイルの内容の方を優先して処理を行う。

だから、添付ファイルなんかを出力する際に、text/plainとかapplication/octet-streamとかのcontent-typeを使っても、.txtとか.binとかの拡張子をつけても、データ自体にスクリプトが含まれていた場合は、実行されてしまう。具体的には、「テキストデータの先頭からnバイトまでの間にHTMLタグらしきものが見つかったら、HTMLとして解釈する」なんて感じの挙動。

以下のサンプルファイルをIEで開いてみれば、どうなるのかわかる。

• test1.html
• test2.html
• test3.html
• test1.txt
• test2.txt
• test3.txt
• test1.bin
• test2.bin
• test3.bin
• test1.jpg
• test2.jpg
• test3.jpg

test1シリーズは単に「<script>alert('test');</script>」ってだけの内容。IE以外のブラウザでは、.htmlの拡張子のもの以外は、スクリプトが実行されないはず。だけどIEでは、.txt（text/plain）、.bin（application/octet-stream）、.jpg（image/jpeg）という拡張子＋content-typeはすべて無視されてスクリプトが実行される。

test2シリーズは、test1の内容の前に無駄なテキスト（数値）を247バイト（改行分は1バイトと数える）つけている。これでもtest1シリーズと同様にIEではスクリプトが動作する。

test3シリーズは、スクリプトの前につけるテキストのサイズを248バイトにしている。こっちはIEでもスクリプトが発動しないはず。おそらくIEは247バイトまでにHTMLタグらしきものが見つからない場合は、text/plainとして扱っているってことなんでしょう。

ただこの境界となるバイト数は、たまたま今手元で試してみた数値ってだけで、ちゃんとした根拠がある数値ではないので、あまり信頼しないで欲しい。

（※追記@2005/5/23 このバイト数に関しては、y-Akiさんのコメントをはじめとする追加情報があります）

というわけで、IEでは正しいcontent-typeをつけても拡張子をつけても、内容としてスクリプトが発動するようなデータだった場合は、スクリプトが発動してしまうので、注意が必要。

ちなみに

Content-Disposition: attachment; filename="foo.txt"

なんてヘッダを指定して、強制的にダウンロードさせる（ダウンロードダイアログを出させる）って手は使えるかもしれないけど、どうも上記指定によるダウンロードって、Windowsのシェル設定（txtのハンドラーを何にするか、とか）によって挙動が変わるっぽいんで、それほど信頼できない気がする。ってのには特に根拠はなく、前にそんなことがあった気がする、程度の情報。

_ もしかしてrecent〜って (22:36)

makerssのデータを使って最近のcommentとかtrackbackを得ているのか？　RSSにcommentやtrackbackを出さないようにしようと、makerssのそれっぽいところを削ったら、recent〜に出てこなくなったっぽい。あとコメント後にエラーも出ているな。ひとまず元に戻しておこう。

_ いろいろトラブってました (22:07)

主にMM/Memoとblogmapで18時くらいからDBエラーが出て死んでいたと思います。で、そのエラーメールが山のように飛んで、メールのウイルスチェック処理（結構負荷が高い）が溜まってしまったため、tDiaryを入れているサーバーにもほとんどアクセスできなくなってしまった、という展開。

DBエラーの理由は、なぜかときどき発生するキャッシング用テーブルのインデックスが壊れていたため。myisamchk -rで簡単に直るんだけど、これなんで発生するんだろうなー。毎回同じテーブルで発生するから、このテーブルの構造か使い方に問題があるんだろうけど、特にこのテーブルが高負荷になるってわけでもないハズなんだけど。複数のマシンで発生するから（今回はマスターサーバーのみ、前回はレプリケーションサーバーのみで発生）、ディスク不良ってわけでもないみたいだし。

アドホックに、テーブルが死んだら自動的にmyisamchkを走らせる監視プロセスでも走らせておこうかなー。

_ Windows環境でバイナリ配布の4.1.11を (13:48)

default-character-set UTF-8で使おうとしたんだけど、my.iniを書き換えても反映されない。もしかしてmy.iniって見てないの？　しょうがないんで必ずプログラムの頭で

set names utf8

とかするようにしてごまかしていたんだけど、ふと思い立ってMySQLサービスの起動オプションに--default-character-set=utf8をつけたら、ちゃんと効いた。そういやそっちで指定する手もあったんだっけ。

それにしても、MySQL 4.1以降はいろいろ扱いが面倒だなー。

_ ゴミを残さずsession_regenerate_idする (16:34)

単にsession_regenerate_idしただけでは、古いセッションIDにリンクしたセッションデータが消えないので、

session_start();
$tmp = $_SESSION;
session_destroy();
session_start();
session_regenerate_id();
$_SESSION = $tmp;

なんて感じで回避していたんだけど、これだと古いセッションIDにリンクした空のセッションデータが残るんでうざいなー（セキュリティ的には問題ないけど）と思っていた。けど、次のようにやればゴミを残さずにセッションIDの付け替えができそうだな。

session_start();
$tmp = $_SESSION;
session_destroy();
session_id(md5(uniqid(rand(), 1)));
session_start();
$_SESSION = $tmp;

新しいセッションIDの生成ロジックは「md5(uniqid(rand(), 1))」でいいのかという点については、要検討。

_ Re:「驚いちゃったよ----ちゃっかりRSS」 (01:22)

blogmapは基本的に私が「ネット上で流れている情報を、できるだけ自動的に整理された形で手に入れたい（自分で情報を整理する手間を省きたい）」という目的のために作ったものです。

• 「ある話題に関して、さまざまな人がどのようなことを言っているのかを知りたい」→「URLがキーになる」→「同じURLにリンクをした記事をデータベース化」→「URLからタイトルを取得して表示」
• 「ある本、音楽、映画に関して、さまざまな人がどのようなことを言っているのか知りたい」→「ISBN、ASINがキーになる」→「同じISBN、ASINが文中に存在する記事をデータベース化」→「ASINをキーにAmazon Webサービスを使って書誌情報等を取得して表示」

公開情報から、URL、ISBN/ASINといった識別コードの類をデータベース化しているだけなので、収集している情報の利用については、法律的には問題ないと考えています。倫理的、感情的には問題がある場合もあると思いますが、それらについては個別対応（やめてといわれればやめる）しています。あと、最近はrobots.txt等も見るようにしつつありますが、まだ完全ではありません。

なんでサービスとして公開しているのかというと、

• 私が便利なものは、他にも便利だと思う人もいるだろう
• ネットワークにそれなりの負荷をかけてデータを収集するんで、その成果はネットワークに還元（公開）しよう

といったあたりの意図です。

また、AmazonアソシエイトやGoogle AdSenseの利用に関しては、基本的に「アフィリエイトを使って、自給自足（ひも付きじゃないお金）で面白そうなサービスを提供してみよう」といった感じでやっています。アフィリエイト収入があればサービスが継続できますし、持ち出しが限界を超えれば、規模を縮小するなりやめるなりして対応します。

サイトの説明の類がないのは、個人がゲリラ的にやっているものなので、ドキュメント化できるほどいろいろなものがまとまっておらず、気が向いたら機能が追加されたり廃止されたりしている、といった感じだからです。あと、ドキュメント書きの暇があれば、代わりに面白い機能の一つでも作った方がモチベーションを維持できるので、そっちに手を出しがちだということもあります。逆に言うと、こういった反応がないとなかなかこういう文章を書く機会ができません。

あと、確かにサイト情報のところの「紹介したメディア」で、うちのアソシエイトIDを使ってリンクを張るのは、いかにもかすめとりっぽさ度が高い気がしたんで（実際には「サイト情報」ページを見る人はほとんどいないけど）、ひとまずそこからはうちのアソシエイトIDは外してみました（blogmapではISBN/ASINしかデータベースに持っていないので、元サイトのアソシエイトIDはつけられません）。

ちなみにJavaScriptが使える環境ならば、「アソシエイト広告ツール」なんてものを使うと、blogmapが収集したデータを元に、好きなアソシエイトIDを使った広告を各サイトに表示することができます（この手の、情報取得元に還元できるような機能を充実させるといいのかなー）。

ひとまずはこんなところで。

_ 速くなったよ！　でも速くなってないよ！ (13:50)

そういや引っ越しをするって話はこっちで書いたんだっけ？　まあ引っ越しするわけなんですが、今までよりも電話局に近いところに引っ越すんで、今まで40Mbps契約で6Mbpsくらいしか出ていなかったADSLが、どのくらい速くなるかちょっと期待していたわけですよ。

で、今日電話の工事が終わったんで試してみたら、ADSLモデムのレポート値で25Mbpsまで来てましたよ。おお、結構速くなってるじゃん！　でも体感速度は全然変わらないし、スピードテストサイトとかでも3Mbps程度しか出なかったけどなー。ボトルネックはどこだろう？

_ この週末は (12:18)

リアル引っ越しで忙しくてネットにつないでいる暇がないんで、そんなときにあんまり面白いことはしないでください。おながいします。

_ 引っ越し一段落 (13:53)

もう予備の土日がない引っ越しはしないと誓う所存であります。

日曜日の朝8時半に引っ越し業者が来るって言うのに、結局梱包が間に合わず、なし崩し的に運搬作業に突入。なんかもうぐだぐだになりながら、当初の予定では捨てるはずだったものも適当に運んでもらいまくり。で、新居の方でも分類不明な段ボールが大量発生してしまい、適当にリビングに積みまくり。ぎりぎり寝る場所だけ確保したものの、子供の保育園グッズとかも行方不明。旧居には、積み残し（梱包残し）の荷物と大量のゴミが残される。

火曜日には旧居を明け渡さなければならないため、月曜日は会社を休んでばたばた残作業。なんとか大量のゴミを処分し、粗大ゴミ回収の手配をすませ、細かい荷物を運ぶ。で、一通り掃除を済ませて、今日の午前中に部屋の引き渡しをすませてだいたい終了。まだ粗大ゴミ回収シールを貼ってないから、その辺を回収日までにやっておかないと。新居の方の段ボールはひとまず今週の土曜日にリビングの新しい家具が到着するんで、それまでに片付けないといけない。

そういや旧居ではキッチン周りのスペース不足で取り付けられなかった食器洗い機も土曜日に届く。いろいろ迷ったけど、よくわからなかったんで、ひとまずスチーム洗浄＋水圧強めってところが良さそうにみえた東芝DWS-60X6を選んでみた。もうすぐ新機種が出るらしいけど、そんなに機能も変わらないみたいだったし、まあいいかってことで。47800円＋分岐水栓代。

今週いっぱいくらいまではまだばたばたし続けなければならないだろうなー。ネット関連でリアルタイムで乗り損ねた話題に、今から反応するべきかどうか微妙に迷い中。

_ Re:「RSSを収集しているサービスは個別のブログに何かを還元できないか?」 (19:07)

に関連して、ちょろっと機能を追加。

商品紹介用HTMLテンプレート作成機能をちょっとだけ強化（パターン増）してみたけど、まあこの手の機能はそれ専用の（テンプレートが充実した）サイトが他にもあるんで、あまり使う人はいないでしょう。もし「こういうテンプレートをつけてくれ」とか要望があったら追加しますよ。

あと、もともとblogmapのメディア系情報RSSでは、associate=your-associate-idなんて引数をつければアソシエイトIDは自由に変更できるようになっているんで、サイドバーにRSSを埋め込み表示したい場合なんかには、適当にご利用ください。メディア系のRSSならば、メディア総合ランキングとか新着メディアランキングとかあちこちで使えます。

さらに、サイト情報の「紹介したメディア」に関してもRSSを配信するようにした（サイト情報ページの「紹介したメディア」の横にRSSリンクを用意した）んで、それに自分のアソシエイトIDを入れると、「最近自分が紹介した商品」のRSSを自分のアソシエイトID付きで取得できます。たとえば、うちのサイトで紹介したメディア情報のRSSは、

http://1470.net/bm/siteinfo/71738/mediarss?associate=your-associate-id

なんて感じ。

さらに、従来のアソシエイト広告ツールの強化バージョンを用意しました。強化バージョンでは、縦に複数個の商品を並べて紹介できるようになっています。APIは、

http://1470.net/api/asin_cms.php?website=[website ID];limit=[表示数];mode=[html/js];width=[表示幅(px)];associate=[アソシエイトID]

なんて感じ。各引数の意味は、

• website - 対象となるWebサイトのID（siteinfoのURLの数値部分）。Webサイトを指定した場合は、そのサイトで最近紹介された順に返す。Webサイト省略時はblogmapのメディアランキングの上位から返す。
• limit - 1〜10の数値。一度に表示する商品数を指定する。
• mode - htmlならばHTML形式、jsならJavaScriptを出力する。テンプレートなんかに埋め込む場合はHTML形式、サイドバーにJavaScriptで埋め込みたい場合はjsを指定する。
• width - 表示幅（px）を指定する。
• associate - AmazonアソシエイトIDを指定する。指定しない場合はishinao-22が使われる。

といった感じです。たとえば、blogmapのランキングTop3をJavaScriptで埋め込みたい場合は、

<script type="text/javascript" charset="euc-jp" src="http://1470.net/api/asin_cms.php?limit=3;mode=js;associate=your-associate-id"></script>

なんて書くと、

なんて感じになります。うちのサイトで最近取り上げた商品五つを紹介したい場合は、

<script type="text/javascript" charset="euc-jp" src="http://1470.net/api/asin_cms.php?website=71738;limit=5;mode=js;associate=your-associate-id"></script>

なんて書くと、

なんて感じになります。

かなりやっつけで用意した機能ですけど、使ってみたい方はどうぞ。

_ アップデートでやられた (19:21)

Win32/Mytob.CY wormとかいう新しいウイルス付きメールが、サーバーのウイルススキャンをすり抜けて来たって言われたんで、最近（本体の）アップデートをかけていなかったclamavをアップデートしてみた。yumで一気にアップデートして、ふつうにメールの送受信ができていたんでOKかと思ったら、添付ファイル付きのメールが扱えなくなっていた。「unknown clamd scanner error or memory/resource/perms」って昔見たことあるな。確か権限周りの設定がおかしくなったときに、このエラーが出ていた。前は、ウイルススキャンするディレクトリに書き込めなくなったってパターンだったはず。で、見てみたら、アップデート前はqscand権限で動いていたclamdが、clamav権限で動いていた。clamd.confを書き換えて再起動して復活。/etc/rc.d/init.d/clamdのUSER設定の変更は効かなかった。