Wiki と荒らし (6)

そろそろこの話題も終わりにしよう。

結城さんより、

spamメールをベイジアンで判定するみたいに、Wikiへの書き込みのspam判定はできるだろうか。書き込みの前後を比べたりして。

という問いかけがあった。

Wiki への SPAM はメールの SPAM と比べて母集団が少ないのがネック（多くても問題だけど）。 でも、 Blog 系の SPAM と傾向は似ているので、サイト間を越えてデータを蓄えていけば、実現できるかもしれないと思った。

• 接続元のIPアドレスもフィルタ対象にすると精度があがりそう（この人は常連なのでスパマーじゃないだろう判定）
• ページを丸ごと書き換えていると SPAM 度合いは高そう
• URL が含まれていると SPAM 度合いは高そう（特にドメインの長いURL）

それから、 UNIX USER 10月号の記事（Wiki, Blogへのスパム対策）を読んだ。 「事前の予防」、「攻撃の検知」、「復旧」が対策として必要なんだと実感。 偽フォームを用意して、ふつうのユーザには CSS で隠しておくという対策は、効果がどれくらいあるのかが気になるところ。

事前の予防について

これは、相手の目的が SPAM なのか荒らしなのかで変わってくると思う。 両者は似たようなものだと思っていたけど、実際に攻撃を受けて別のものだと実感した。

スパマーは広告が目的なので、費用対効果という経済の論理で動いてくれる。 だから、チェックボックスや、ワンタイムトークンを使った仕組みが有効になる。 （そのサイトに特化して攻撃する時間があれば、他所のサイトを狙った方が効率がいいから）

でも、荒らしは愉快犯なので、この論理が通用しない。最近のチェックボックス付き tDiary を狙った攻撃のように、防御を破ることに喜びを感じているっぽいし。 IP アドレスを毎回変えてくるような相手に、ワンタイムトークンがどこまで通じるかは少し疑問。 毎回、編集画面を GET で取得して Form をパースされれば破られちゃう（Perl などのモジュールを使えばこれは簡単にできそう）。

ボタンをたくさん作っておき、ボタンごとに POST 先を変える方式は有効かもしれない。 CSS を使って、ふつうのユーザには正しいボタンだけを見せるようにするとか。 後は、どこかで見たネタだけど、テキストボックスにワンタイムパスワードを入力される（ふつうのユーザはJavaScriptで自動的に入力する）とか。

どっちにしても、 CSS や JavaScript という、自動化しづらい要素を使うのがポイントか。

復旧

あまり話題に上らない気がするけど、攻撃を100%防ぐのが無理な以上、復旧の手間は重要なポイントだと思う。 簡単に復旧されるようだと、荒らしもスパマーも敬遠するだろうし。

• 特定の日時の編集をまとめて元に戻す
• 特定の接続元からの編集をまとめて元に戻す
• 特定の内容を含む編集をまとめて元に戻す

という機能があるといいな。 シェルを使える環境なら、ある程度は自動化できるけど。