■
■ アカウント取得
なんか俺が作ろうとしているシステムと、Wiki＋日記という基本線が結構似ていて気になっていたはてなダイアリー。最近遊んでいる暇がとても少ないんで試している余裕はないだろうと、最初のβテスター募集は見送ったけれども、追加募集の人数増加の具合がさほど激しくなさそうだったんで、それならあんまりばりばり使わない人間がアカウントをもらっても罰は当たらないだろうという言い訳を思いつきつつアカウント取得。
今俺の頭の中にある俺が作ろうとしているシステムは、Wiki＋日記というよりは、キーワードリンクを有効に使ったCMSといった感じにポイントが発散してしまっていて、現在のはてなダイアリーシステムとは結構違ってしまっているけれども、途中で日記システムとしての機能を中心にしても面白いかもしれないと思ったこともあったので、その時点でそっちに転んでいたら、現在のはてなダイアリーによく似たシステムを作っていたかもしれない。
■ キーワードリンクのアプローチ
キーワードリンクを有効に使う手段としては、Wiki的なアプローチ（ユーザーが明示してキーワードを登録・管理する）と、ワーズナビ?的なアプローチ（システム側で有効なキーワードを登録する）という大きく二つの方向性があり、どちらにも利点・欠点がある。はてなダイアリーはWiki的なアプローチをメインに据えつつ、キーワード管理ツールを用意することによってキーワードの質をコントロールしようとしているのだろう。キーワード管理の部分はどういう風になっているのかまだ知らないので、まずはその辺りを調べてこよう。
■ ユーザー管理
そういやはてなダイアリーは、もともとのはてなのアカウントを利用してユーザー管理をしているんで、はてなシステムユーザー（最低限メールでの認証済みのユーザー）というレベルでユーザーを認識することができるんだよな。これは他のシステムとはちょっと違った特徴だ。だから、「はてな登録者のみツッコミを許可する」なんてことができ、最低限の閲覧者管理も可能になる。でも、新規に立ち上げるシステムなんかではいちいちユーザー登録を求めてなんかいられない（間口を広げたいなら）から、そうそうほかのシステムで真似するわけにもいかないけれど。
■ セキュリティ的な問題
を一つ思いついてしまった。で、その内容を書きかけたんだけど、本当だったらまずい気がするから、公開する前にはてなに問い合わせてみよう。
と問い合わせたらもう返事が来たアンド対処が終わったみたいなんで公開（次の段落）。
■ Cookie盗難の可能性は？
「はてなのアカウントを使ってユーザー管理をしている」と書いたところから思い当たってしまったセキュリティ的な問題。はてなって一度ログインすると次回アクセス以降もログインしなくても良くなっているってことは、たぶんCookieにユニークなログイン情報を記録して、ログイン管理をしているんだよな（有効期限長そうだ）。で、はてなダイアリーでもそのCookie情報にはアクセスできている。さらに、はてなダイアリーでユーザー（日記作者）は自由にHTMLタグを書くことが可能だ。ということは、JavaScriptコードを書いてアクセスしてきた人のCookie情報を取得することは難しくなさそう。それを別サーバーに記録することもそんなに難しくない。もしも盗んだCookie情報のみを使って他人になりすましログインできたりするとかなりまずいことになる。
という件については、すでにはてなのサポートに連絡済みで、対処済みです。
■ 一部タグを禁止する対処法
ところで私は、パターンマッチ?で一部タグを禁止する方法では、XSSは完全に防げないという定説を、特に検証もせずに信じていたんだけど、はてなの対処策にも穴があり得るのかな。イベントハンドラ全面禁止＋スクリプト系タグ禁止にすることで、ぱっと思いつく穴はだいたいふさがっていると思うんだけど。と書いているうちにほかの穴の可能性を思いついてしまった。ちょっと試してみよう。
という件についてもはてなのサポートに連絡済みアンド対処済み。これでブラウザから試せるレベルの俺が思いつく穴は一通りふさがったかな。ブラウザ依存のレアなケースとかブラウザから手軽に試せないパターンは面倒くさいので未チェック。まあはてなは基本的にJavaScriptに依存していない作り＆俺は普段JavaScriptオフが基本なんであんまり害はないし。
■ ゲームとして楽しい
とかいいつつ、まだ穴を捜していたり。XSS穴探しって知的ゲームとして楽しいなー。しかも、大義名分も兼ね備えているんで、やり始めるとかなりはまる。でも、あまりにも面白すぎるんで、それに（知的ゲームという方向から）はまると自分のリソースが食われて、ほかのことができなくなってしまいそうだ。できればXSSなんてのは根本のレベル（ライブラリとか）で対策して、あとは気にしないで済むようにしたいなー。というPHPのフレームワークを作りかけているんだけど、使い勝手の良さとセキュアさとを同時に兼ね備えるのは難しい。汎用性って言葉はやっぱり毒だよな。
■ 根本的な対策
とかいいつつ、もう一つ穴を見つけて報告。やっぱり「パターンマッチで一部タグを禁止する方法では、XSSは完全に防げない」定説は正しい気がするよ。たとえ現在のブラウザにおけるすべての穴を塞いでも、将来のブラウザ拡張とかによって新しい穴が開く可能性はあり得るし。
HTMLタグの直接記述を許す限りはXSS対策は完璧になり得ないので、HTMLタグの直接記述をやめて何らかのコマンド（ハイパー日記システムのhnf?や各種WikiClone?における記述ルール）をクッション（フィルター）として利用する方法が無難だろうな。俺だったらその手を使う。
HTMLドキュメントをエレメント単位でParseして、各エレメントごとの属性をチェックする（パターンマッチではなくDOM?レベルですべてのエレメントに対してセキュリティチェックをかける）という手も理論的には有効だと思うが、こちらはあまりにもコストが高すぎて現実に利用するのは難しいだろう。前にそれ系の方法を試してみたけれども、サブセット的に実装するのも結構きつかった。
