• 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認証でも大丈夫だよね。