Wiki と荒らし (4)

いかに簡単に元の状態に戻せたとしても、また簡単に書き換えられてしまうようでは結局いたちごっこになってしまう。

そこで、いくつか対策を考えてみた。

相手が諦めるまで何もしない

いわゆる根比べ。 相手が SPAM 目的だとすると、簡単に元に戻されてしまうことが分かれば攻撃を諦めるかもしれない。 でも、相手の目的が SPAM でなくサービス停止（いわゆる荒らし）の場合は、復旧するまでの間だけでも目的を達成されてしまうので、これは NG 。

書き込み時にチェックを加える

チェックボックスをつけたり、機械的に読み取れない画像に書かれた文字を入力させたりする方法。

チェックボックスは、いきなり POST してくるようなスクリプトには有効だろうけど、アクセスログを見る限り、編集画面を GET した後に POST してきている。 編集画面の Form データを解析されたらアウト。

画像文字の入力は強力な対策だけど、ふつうの利用者の手間が増えすぎる。 1人の荒らしのために、大多数の利用者のユーザビリティが下がってはダメだろう。

パスワードで制限をかける

利用者が少人数であれば有効かもしれない。 でも、大人数で使う場合は、パスワードの配布方法が問題になってくる。

パスワードをページに書いておく方法は、 Spammer には有効かもしれないけど荒らしには効果がなさそう。攻撃スクリプトを1〜2行修正すれば、パスワード認証なんて突破できちゃうし。

それに、やっぱり利用者に不便を強いる時点で NG 。 TypeKey認証を使う方法もあるけど、TypeKeyアカウントはまだまだ普及していないし。

編集した人を特定できるようにする

これまでの対策は攻撃を未然に防ぐためのものだけど、これは攻撃を受けたあとに対策を打てるようにするもの。

一般に、攻撃者は匿名プロキシを経由して接続してくる。 これを禁止することで、攻撃の被害を受けたときに、攻撃者を特定できるようになる。 まぁ、どこの誰かが分かる訳じゃなくて、ただIPアドレスが分かるだけなんだけど、それでもそのIPアドレスをブロックすることや、悪質な場合はプロバイダや接続元組織に苦情を出すこともできる。 それに、ふつうの利用者が匿名プロキシを使う動機はまずないから、利用者のユーザビリティも下がらない。

匿名プロキシからの接続を禁止するには、匿名プロキシを明示的に指定するブラックリスト方式と、逆に許可する接続元を明示的に指定するホワイトリスト方式が考えられる。 メールの世界ではブラックリスト方式が主流みたいだけど、HTTPプロキシは常に新しいサーバが登場している状況で、特定するのは大変っぽい。

なので、多少乱暴ながらも、jpドメインからの接続のみ受け付けるようにして、順に許可リストを増やしていくホワイトリスト方式を採用することにした。 DNSの逆引きができないアドレスからも接続禁止。

さて、どうやって実装するか…（続く）