MTの脆弱性か否かという話は僕にとってタイムリーでした。
ログインプロセスを簡略化するためにクッキー認証を使いたいんだが、何ならOKで何ならダメかということのガイドラインがほしいなぁと思ってたので。

クッキー認証の問題点は、クッキーが漏れるとログインできてしまうというのと、CSRF（Cross-Site Request Forgeries）というものである。クッキーの正式な所有者に、問題になるURLを踏ませることで何がしかの攻撃ができるというもの（はまちちゃん問題がコレ）

詳しくは他サイト参照。
「ぼくはまちちゃん」 ――知られざるCSRF攻撃
Movable Type における CSRF の可能性と各種対処法

とはいえだな、amazonにせよ、クッキー認証で何がしかの状態は復帰されるわけで、そのものが根本的に悪ということではない。コレを使いたいからには何に使うか？ということを見極めて使えというわけですな。

で、是非、自動ログインをなんとかしたいのでいろいろ考えてみる。

１．自動ログイン可能な入り口は固定しておくことで、コーディングミスなどによるCSRFの発生は避けられる。（なんとも消極的だが）、URLのブックマーク対策には、ログイン＆リダイレクトするようなプログラムを一度経由させてログイン。（これは、イマイチ）

これによりログイン処理をあっちこっちに持たせないようにするのと、CSRFによって被害を受けるようなページは、ログインなしでは動かないようエラーにしておけば、デバッグ時はURLを叩くだけで検証ができる。
（本来のセッション維持は、Appサーバ実装のセッション変数を使う。）

２．個人情報を扱うところと、カード番号を入力する直前は、今一度、ユーザーID、パスワードで認証を行い、クッキーが漏れたときの損害とのトレードオフを考える。（アマゾンがこれですな。）

３．クッキーの有効期間を1週間や数日にしておき、ログイン時は、ID＋パスワード＋時間でハッシュ化してDBに保存しておき、ログイン時にID認証と時間を変数に使った暗号で認証する。時間をパラメータに使うことで毎回同じ値を出力しないで推測しにくくするためのものである。（意味ないか。）

HTTPリクエストをキャプチャされたら漏れる件は無視。どうせその場合は、この認証を使わずともID、パスも漏れるからSSL使わないことには、セキュリティレベルは同じでしょ？

と、まぁそこまで書いたところで、ホントに興味ある方は、下記を参考してくださいまし（ｗ

クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法

上記の記事を参考にすると、さほど問題ではなさそうな気がするのだが、どこぞに報告すると脆弱性として認められるという話もあり、さて重要度はどんなものなのでしょうか。