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

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

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

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

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

vuln-inq@ipa.go.jp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

昔どこかの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のハンドラーを何にするか、とか）によって挙動が変わるっぽいんで、それほど信頼できない気がする。ってのには特に根拠はなく、前にそんなことがあった気がする、程度の情報。

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

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

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

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

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

set names utf8

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

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

単に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))」でいいのかという点については、要検討。

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を使った広告を各サイトに表示することができます（この手の、情報取得元に還元できるような機能を充実させるといいのかなー）。

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

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

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