多くの Trackback サーバの実装に関して、容易に Trackback SPAM のターゲットにできる脆弱性が存在しますので、内容と回避法についてアナウンスします。

これってTrackbackに限った問題なんだろうか？　HTTP POSTで攻撃可能なすべてのWebアプリケーションに有効だったりしそうな気が。

抜本的に対策するのならば、

5. Trackback プロトコルのバージョンを上げて、こうした悪意のあるアタックを回避できるようにする。

になるんだろうけど、どうやっても（TypeKeyみたいに）利便性とのトレードオフになりそうだ。

一般的な掲示板と同様に、

• 基本は世間の善意を信じて解放しておく
• どうしても厳密に対応したい場合のみ、受付は無制限だけど、表示には管理人チェックが必要（デフォルト非表示）にしておく

というやりかたしかないんじゃなかろうか。

早速miyagawaさんからツッコミが

1. 通常の掲示板のようなものならば、Referer が自分のドメインかどうかをチェックすればDDoSの対策にはなる（プロキシ経由スクリプトなどの攻撃には無効）。Trackback はそもそも正規のものがブラウザからのものではないのでRefererチェックはできない。

2. Trackback のパラメータは規格化されて決まっているので、任意のアプリケーションより攻撃が楽（汎用的な攻撃スクリプトが書ける）。

確かに、

• 規格化されているので狙いやすい
• 基本が他サーバーとの通信なので、環境変数等で弾きにくい

って理由で、trackbackが同種の攻撃に対して（一般的な掲示板などよりも）弱いってところはあるだろうなー。

目先の被害が大きそうなtrackbackに関して、対応策を練る必要はあるだろうけど、個人的にはこの手の問題は、trackbackの問題に限定せず、

• 従来型の（世の中を基本的に信頼した）Webアプリケーションの作り方自体がそろそろ限界に達しているのではないか

という視点で捉えた方がいい気がする。んでもって、一般論としての対策を練って欲しい（←他人事かよ！）。日記やらblogやらwikiやらCMSやらの連携について議論するMLあたりでなんとかしてくれんかのう。どの辺を落としどころにしておくのが無難なのかのう。

ってことで、おまけにふと思いついた対策（ネタ）。

• trackbackのインターフェースが簡単なのが悪い。もっと面倒くさいインターフェース、たとえばSOAPベースにしちゃえば、厨房spammerはあきらめるだろう
• accept-language: ja、accept-charset: shift_jis, euc-jpじゃないとtrackback（あるいはHTTP POST）は受け付けないようにしよう。鎖国政策だ！