この記事は「外部URLからの（自動）POST攻撃への対策」に移動しました。

はてなでは

file://と自ドメイン以外からのPOSTをREFERERを見てはじいているみたいだな。はてダラは通るのかな？　まあはてダラみたいなツールでは、REFERERを偽造しちゃえばそれですむだろうけど。

ちなみに

この問題は無差別攻撃ではなく、あくまでもピンポイントで狙われたときにのみ攻撃されるというものなんで、一般的なブラクラみたいに広範な影響はないでしょう。

広範な影響がありました

「はてなの例のexploit 続き」で例として挙げられているように、pingサイト＋trackback（or コメント）＋refererのコンボを使うと、結構大量に攻撃できそうですね。refererを使うってのは思いついていなかった。

「日記ツールで下書き、blogツールで清書」というポリシーに従って運用しつつあるんだけど、どのタイミングでコンテンツを移動するべきかが難しいな。大きく分けると、

• 書いてしばらくして、一通り言及され終わってから移動
• 書いてすぐに（まだ言及されないうちに）移動

という二つのタイミングがあるわけだけど、最終的なコンテンツURLは移動後のものになるんだから、できれば移動後のURLで言及される方がいい。けど、ほとんど寝かさずに移動してしまったのでは、わざわざ日記ツール上で下書きしている理由の一部（練りが荒い状態のテキストを日記ツール上で叩いてもらって、ある程度もまれた結果をblogツールへ移動する）に意味がなくなる。

あと、移動する際にはできるだけ元のテキストを残しつつも、独立したコンテンツとして成立するように微妙に編集していたりするんだけど、その辺の改変度合いも難しいな。自分ではどうでもいいと思って改変した部分も、人によっては重要だったり（改変じゃなくて改ざんだ！とか）しかねない。でもコンテンツが二重化するのはいやなんで、基本的に元テキストは削除した上で移動したいしな。やっぱり履歴管理ツールと連動する仕組みがほしいなー。

基本的なオブジェクトはあのくらいにシンプルにしつつ、ネットワークを自分を中心とした1:nよりももうちょっと先まで（n階層先まで）一気にたどれるようにして、3D表現を使って表示すると結構面白そうかも、とか思った。

前に3D方向に展開するBBSってのを考えたことがある。一般的なツリーBBSみたいに、ある発言に対してレスポンスをつけられるんだけど、そのときにレスポンスの方向をn方向（賛成、反対、別意見とか）で表現できるようにする。それを表示するときには3次元のネットワークとしてレスポンスのつながりが展開され、閲覧者は自分が興味のある方向へと話題の流れを追っていく。仕組みは（たぶん）面白いけれども恐ろしく可読性が低そうなBBS。

ただ、面倒くさそう（3次元表現を駆使するためには結構巨大なJavaScriptライブラリを作らなきゃいけなくなる）な割には、実用度が低くて一発ネタにしかならなそうなんで、実際には作らなかったんだけど、これをSNSでやると結構良さそうに思える。というのは、実用性・可読性の低さがSNS的なネットワークのつながりを表現するのに、ほどよい不自由さとなってくれそうだから。

思い通りに操作できて思った通りの結果が出てくるものは、実用性は高いけれども遊べる余地は少ない。ほどよい揺らぎや予想外の動作があってこそ、面白みが増す（って、はてなダイアリーのキーワードについて語っているみたいだな）。上記のようなインターフェースでつながりを表現することによって、きっちり正規化されたまともなデータベースを使っていても、ユーザーインターフェースのレベルで揺らぎや予想外の動作が発生してくれて、面白いことがおきそうな気がする。

「人」と「枝」と「物」という三つのエレメントから構成するといいかなー。「人」は参加者自身。「物」は参加者以外のあらゆる事物人。「枝」は、「人」と「物」、「物」と「物」とを結ぶ接続方法。「枝」はある程度種類を絞っておいた方がわかりやすいかな。「好き」「嫌い」「持っている」「興味がある」「賛成」「反対」とか。「人」と「物」のつながりはともかく、「物」と「物」のつながりをどう管理するかが肝になるな。「物」には「クラス」と「インスタンス」があって……とかまでやり始めると無限に仕様がでかくなってしまいそうだ。

なんてことを今はやっている場合じゃないのですよ。現実逃避は筆が進む。

TypeKeyをちょっといじってみたんだけど、これって本当に大丈夫なんだろうか？　まだベータ版程度の出来なのかな？　正常系は動作するみたいだけど、異状系の処理とかセキュリティ関連のポリシーに不安を感じる。ってだけ書くとFUDって言われちゃうかな。一応俺の環境で起こった例を挙げておこう。

MT3.01D-jaで構築したサイトで、コメント設定をTypeKey（＋メールアドレス通知）必須にしておく（TypeKeyなしの場合は管理者チェック付きで許可）。んで、適当なページからTypeKeyのサインインに飛んで認証しにいく。メールアドレス通知が必要だといわれるけれども、「メールアドレスを通知しない」を選択して認証する。すると、認証失敗が返るんだけど、コメント投稿フォームのメールアドレス欄になにやら怪しげな16進数文字列が入っている。実害はないが気持ち悪い。

さらに、その状態で元のページに戻ると、なぜかTypeKeyの認証が通っていて、コメントが投稿できるようになっている。どうやらメールアドレスを通知しないを選んだにも関わらず、メールアドレスが通知されてしまっているらしい。その状態でコメントを投稿すると、ちゃんとコメント者のメールアドレス欄が埋まっている。

まあメールアドレスの通知・非通知は個人的には大して重要ではない部分だし、どうせTypeKeyの個人情報リンク先にメールアドレスが表示されちゃうことを考えれば、メールアドレスの通知・非通知という選択自体あまり意味がない気がするんだけど、ちゃんと動いていないっぽい雰囲気が気になる。試しにtDiaryにTypeKey認証をつけてみようかと思っていたんだけど、こんなんだと出だしからやる気がそがれるなー。

• attacking MT 1 from SG::Acme
• MT 2.x をインストールしたら真っ先に行うべきセキュリティ対策 from hxxk.jp

あたりで語られている脆弱性の話。出遅れたんで詳細がよくわかっていないんだけど、おそらくJavaScriptを使って特定（管理系CGI）のURLに対して（投稿や削除などの意味を持つパラメータ付きで自動的に）POST（submit）させる（ことによって意図しない処理を実行させる）って話だよね。それだったら、認証情報をCookieで維持するサービスだけでなく、BASIC認証でログインさせるサービスも対象になると思う。

上記URLで紹介されている対策は、

• 管理ツールURLを外部から類推されないようにする
• REFERERチェックを行い、外部からのPOSTは弾く

ってあたりみたいだけど、REFERERチェックってセキュリティソフトとの相性が良くないから、それで対策するってのも結構微妙だ。

JavaScriptデフォルトオフにしている人間は比較的安全そうだけど、MTなんかだとJavaScriptオンじゃないと使いづらいから、その辺をいじっているときに引っかかっちゃう可能性はありそうだしなー。まあでもMT管理ツール（から派生した）タブ以外はオフにしておけば、だいたい大丈夫だと思うけど。

抜本的な対策の案としては、あらゆるフォーム操作でフォームを生成する段階で、正しいURL（管理ツール）でしか知り得ず（Cookieとか）、なおかつ他人に知られてもさして害がない（寿命が短くてクリティカルではない）情報を埋め込んでおき、POSTされた段階でそれをチェックするって方針を徹底すれば、その手の攻撃は防げそうだ。

認証管理にセッションIDを使っている場合は、セッションIDの一部（のmd5ハッシュ値とか）をhiddenで埋め込んでおいて、それでチェックするってのはどうだろう？　セッションIDの一部だったら漏れてもたいした問題じゃないし、照合も簡単だし、寿命も比較的短いだろう。ただこの方法は、BASIC認証の場合や、セッションIDを持たないCookieベースの認証では使えないなー。

もう一つの抜本的な対策案としては、普段ブラウジングに使っているブラウザと、更新管理とかに使うブラウザを別にするという方法。普段IE系ブラウザを使っている場合は、更新管理はFirefoxを使うようにすれば、管理ツールの認証情報はFirefoxでのみ維持されるんで、IE上で攻撃URLを踏んでも自動認証されたりはしなくなる。これならBASIC認証でも大丈夫だよね。

「ウェブロについて考える。６の599（ime.nu経由）」より、

>MTに限らずCookieやBASIC認証を使った全てのCGIで似たようなことは出来る。

はFUD

ちなみにtDiary（BASIC認証）でもできますよ。別タブ/ウィンドウとかで管理画面をBASIC認証済みにしておいて（ブラウザを閉じなければ、そのページ自体は閉じてもOK）、別に登録フォーム相当のHTMLを持つページを用意し、実行ボタンをhiddenパラメータ化しておいて、JavaScriptでsubmitさせる。IE系でもMozilla（Firefox）でもできた。

タブブラウザユーザーの場合は、そういう運用（別窓で認証した状態をキープ）って珍しくないよね。BASIC認証を切るためには、いったんタブブラウザごと閉じなきゃいけないんで面倒だし。まあMTみたいにブラウザセッションを越えて認証状態を継続できない（でもMTのその機能もオプションだけど）んで、ちょっとだけましだけど。

あと、個人的にREFERERで縛るのって、ユーザー環境によっては誤動作する可能性があるし、その場合の対応が面倒なんで（セキュリティソフトONで動かない場合、セキュリティソフトをOFFにしろとは言いにくい）あんまりやらないんだけど、一般的には標準だったりするのかな？

まあやっぱり抜本的な対策として、セッションIDの一部をhiddenパラメータで埋め込んで認証するほうを（自分の）標準にしようかな。BASIC認証の場合は、REMOTE_PASSWORDの一部のmd5ハッシュとかかな。REMOTE_PASSWORDって使ったことないんだけど、BASIC認証を通った場合は必ず得られるんだっけ？

そういえば、「ウェブロについて考える。６の596（ime.nu経由）」にある、

Yahooとかみたいにワンタイムのクッキーでうにゃうにゃすればいいような…

に関する具体的な情報希望。ちなみにMy Yahoo!で試してみたけど、まあふつうに同様の操作（他のフォームからJavaScriptを使って勝手に更新）ができたよ。ワンタイムってのがどの程度の寿命なのかよくわからないけど、ブラウザセッションCookie（ブラウザを閉じるまで有効）だったら大して差がない気がする。というか、どちらにしろフォーム（に含まれる情報）とCookie（に含まれる情報）を照合する仕組みがないと意味がない気が。

まめにログアウト（セッションCookie削除）できるようにするのは簡単だけど、ユーザーがそんなのいちいち使ってくれることを期待しても無駄っぽい気がする。MTだってログアウト機能はついているけど、更新が終わるとログアウトする人なんてあんまりいないと思うし。

REMOTE_PASSWORDはだめっぽい

PHPだったら、$_SERVER['PHP_AUTH_PW']でいけるんだけどなー。しょうがないから、一般的なBASIC認証の場合は、REMOTE_USERと適当なシードを組み合わせて生成する方向かなー。

tDiaryだと

update.rhtmlとpreview.rhtmlに、

<input type="hidden" name="authkey" value="<%= Digest::MD5.hexdigest(ENV['REMOTE_USER']+'some unique seed') %>">

なんて感じで埋め込んでおいて、クリティカルな処理時は、

if @cgi.params['authkey'][0].to_s != Digest::MD5.hexdigest(ENV['REMOTE_USER']+'some unique seed')
die
end

って感じかな。

実際には'some unique seed'は@confにセットするか、あるいはサーバー上で非公開の使えるキーを自動生成。tdiary.confのmd5値とかどうだろう？　クリティカルな処理は、TDiaryAppendとTDiaryUpdateあたりでいいのかな？

PHP＋BASIC認証の場合

<input type="hidden" name="authkey" value="<?php echo md5(substr($_SERVER['PHP_AUTH_PW'], strlen($_SERVER['PHP_AUTH_PW']) / 2)); ?>">

なんて埋め込んで、

if ($_POST['authkey'] != md5(substr($_SERVER['PHP_AUTH_PW'], strlen($_SERVER['PHP_AUTH_PW']) / 2))) {die('不正な投稿処理');}

とか。フルにパスワードを使うのが気持ち悪いんで、なんとなく後半半分だけ使ってみた。

PHP＋セッションCookieの場合

<input type="hidden" name="authkey" value="<?php echo md5(session_id()); ?>">

なんて埋め込んで、

if ($_POST['authkey'] != md5(session_id())) {die('不正な投稿処理');}

とか。セッションIDの一部にしなくても、セッションID全体のmd5ハッシュで十分か。

そういえば

DI:DOみたいに、クリティカルな処理をするときには必ずパスワードを入力させる、という方法もあるんだよな。んでもって、クリティカルじゃない処理はCookieによる認証で済ませる、と。

ただそうやってクリティカルな処理のたびにパスワードを入力させると、パスワードの強度が下がるリスク（頻繁に入力するなら簡単にしたくなる＆パスワード文字列が頻繁にネットワーク上を流れるんで漏洩機会が多くなる）もあるんだけど。

HNSも

webifの記事投稿時はパスワード入力必須だったんだっけ。すっかり忘れていたな。

結構シンプルなツール側の対策を考えてみた

簡易認証用のPATH_INFOを必須にするってのはどうだろう？　たとえば、tDiaryだったら管理CGIファイル名はupdate.rbなわけだけど、適当なPATH_INFO設定（たとえばabc）を@confで定義できるようにして、update.rb/abc?[QUERY_STRING]じゃないと管理CGIが動作しないようにする。

もしもPATH_INFOなしでアクセスされた場合は、ユーザー認証済み（BASIC認証の場合は認証後じゃないとcgiにはアクセスできないわけだが）だったら、自動的にPATH_INFO付のURLにリダイレクトする。そうすると、そのフォームからREQUEST_URIに対してPOSTするぶんにはPATH_INFOが維持される。PATH_INFOなしでアクセス（＝攻撃？）があった場合、自動的にPATH_INFO付きURLにリダイレクトする際に、QUERY_STRINGやPOSTパラメータが除去できるんで、攻撃が無効になる。

mt.cgiをリネームしよう案と似ているけど、いちいち実ファイルをリネームするのではないぶん手軽で、同様の効果（投稿先URLが違うので処理が働かない）がありそう。表側に管理ツールへのリンクを張る際も、update.rbのままでかまわないし。管理CGI側でPATH_INFOを使っていなければ、内部的には処理を書き換える必要がない。単に処理の最初にPATH_INFOの正当性チェックコードを入れるだけ。

この仕組みに穴はあるかな？

ああ、いかん

REQUEST_URIじゃQUERY_STRINGも維持されちゃうじゃないか。PHP_SELFの方だな。って、これはPHPだけの環境変数か。えーっと、一般的なCGI環境変数にPHP_SELF相当（SCRIPT_NAME＋PATH_INFO）ってないのかな？　いちいちSCRIPT_NAME＋PATH_INFOって書かなきゃだめなのか？

その 5. お客様の書いた文章より長い文章で返答せよ。

      熱心さがお客様に伝わる

すげーなー。こういう虎の巻があってもいいとは思うけれども、普通は部外秘とか社外秘扱いになる代物なんじゃなかろうか。というかもしもメールワイズというのが、この条項を支援してくれる機能があるなら、ちょっと見てみたいかも。官能小説自動生成ソフト「七度文庫」（via void GraphicWizardsLair( void ); //）みたいなものになるのかな。

各所で話題になっている「XMLウォッチ: Planet Blog」って、「特定の記事のRSSを取得する方法」で話題にした、RSSを利用したWebマガジンと似ているな。

Planet Blogの説明を読むと、単にを特定の技術傾向を持つフィードを集めているだけみたいだけど、どうせなら俺案みたいにtrackbackを使ってユーザーサイドからのアクションでデータを収集するパターンも取り込んでほしい。

あとRSSを収集する際に、特定のカテゴリーの記事のみのRSSを取得するようなフィルタリング処理もあったほうがいいよな。参加者同士でカテゴリー指定方法を決めておいて、そのカテゴリーの記事だけ収集したりとか。RSS（っていったいどのバージョンをさしてるんだよ、コンチクショー）にカテゴリー指定ってあったっけ？

とある理由で、自分の過去の日記を読み返していたら、面白いネタがあったので引用。

「1.魎魍魅魑」「2.魍魎魑魅」「3.魑魎魅魍」「4.魎魑魅魍」「5.魑魍魅魎」「6.魑魅魑魎」「7.魍魅魍魎」「8.魑魅魍魎」「9.魑魅魍魎」。さて正解はどれ？

まじわかんねー。

「本物？偽造？ブッシュ軍歴疑惑の証拠文書を巡り大論争」から、「ブッシュ軍歴疑惑の証拠メモ偽造事件：タイピストの証言」という展開へ。

この話って、スカパー！のドキュメンタリー系チャンネルとかで特集してくれないかなー。