Jack's Room開発室

すっげー久しぶりにここ書きます、Jackです。

今日は会社が休みなのですが、昼過ぎに起きて掲示板見たら、SPAMの大量爆撃くらって一ページ目から人間の書き込みが完全に追い出されている事態に遭遇しました。

さすがにちょっと頭に来たので、久しぶりに対策取りました。

今回採用したのは
「入力してはいけないフィールドを用意する」
という一見よくわかんない方法です。

掲示板を開くと、入力フォームの下のほうに「ここは入力しないでください」というテキストフィールドがあります。ここに入力されると投稿を受け付けません。

そして、ソースを見るとわかりますが、このフィールドの名前が「mail」になってるんですね。動的にフォームを解析したSPAMエンジン（っていうのか？）は、ここをメールアドレス入力欄だと解釈して値を設定するわけです。本物のメールアドレス入力欄はぐちゃぐちゃな文字列で名前つけてます。

たぶん、こいつでまた当分は平和になれます。

これで実に4通りものチェック処理が追加されてしまいました

A.パラメータが不正なもの
うちの掲示板の元になったスクリプトの入力パラメータを固定的に投げてくるものに対応する。

B.大量のURLを含むもの
6個以上に設定、数百以上URLを含んだ書き込みがよくあるので、これがないと掲示板が使い物にならなかった。

C.タイトルなし、または「None」の禁止
たまたま多かったタイプにこういう書き込みがあったからで、これが一番その場しのぎな対処だったかも、けっこう効果はあったけど。

D.入力禁止フィールド（偽メール入力欄）の追加
今回やった奴です、本当はこのチェックだけでABCのほとんど全てをカバーできるはずですが、なんとなくタイプ別にログとっているので、他のチェックも残して、このチェックを一番最後に回しています。

ちなみに、今さっきDの対策を行ってから、この記事を書いている間にもうタイプA、B、Dそれぞれに一件ずつ引っかかっています。

・・・これじゃ、掲示板なんてもう、まともに使えないんじゃないだろうか・・・最近はメールも、以前のようにメールアドレス公開するとまともに使えない（週に数回だけ家に帰る私は帰るたびに数百通のSPAMを受信するハメになる、いくらフィルタがあっても苦痛だ）し、なんていうか、ネットワークはSPAMに押し潰されつつあるような、そんな気がしてならない。

まあ、もうしばらくたったらログ集計してそれぞれの件数でも数えてみたりするかー。

久しぶりに開発室からの投稿です。

サイトのトップページとかから見て違うブログに飛ぶと驚かれそうなのでタイトルに開発室と明記しておきました。

しかし、最近色々不可解なことが起こってるんですよね・・・
いや、怪奇現象とかじゃないよ

うちの掲示板、なんかspam系な書き込みですぐいっぱいになります。
まあ、これは以前から続いていたことです。

ところが・・・今度はなんと、作品の感想にspam書き込みが来るんですよ！
そんなバカな・・・
何故これがバカな、と驚くことになるのか説明しよう。これまで私は以下のような推測で掲示板にspam書き込みが届くものだと思っていた。

1.spam書き込みは自動化されたプログラムによって行われているはず。

2.自動化できるのは、うちの掲示板プログラムがネット上で沢山使われているフリーウェアで、仕様が広く知れ渡っており、この掲示板に対応するだけでネット上の多くの掲示板に対応できる。つまり、対応するコストに結果が見合うからである。

3.そして掲示板spamプログラムはネット上を同じプログラムの掲示板を求めてさまよい歩き、見つけたものに対して書き込みを自動的に行う。

ところが今回、Jack's Roomの感想にspam書き込みが入ったのだ。

うちの感想のプログラムは私がうちのサイトのためだけに書いた「一品モノ」である。

一品モノのプログラムに対して、個別に書き込み機能を実装していては手間がかかりすぎるので、まずそんなことはしないだろう。

一品モノに対応する簡単な方法として、人力で書き込むことが考えられる。ふつうに人力でうちのサイトにたどり着いて書き込む限りは未知のプログラムであろうと関係ない、ただ入力項目を手で埋めて書き込むだけだ。

ただし、人力はコストがかさむし、書き込まれた結果がうまく表示できていないことからも人力による書き込みではないと思われる。

すると、考えられる方法がもうひとつ。

htmlを読み込んで、内容を解析してあてずっぽうにデータを送信しているのではないか？

プログラムがhtmlを解析したところで、それが掲示板のようなプログラムの入力画面なのか、なにかのメール送信フォームなのか、検索条件の入力なのか、完全には解らない。でも、なんとなくで判断して当てずっぽうに書き込んでしまうのなら、ある程度まで推測できるだろう。

フォーム中にテキストエリアが存在するなら、多分そこが本文であり、そこに宣伝文を書き込めば画面にもっとも効率的に表示されることが推測される。

その他の入力項目は必須チェックにひっかかる場合があるのでとにかく何かを入力してやれば、大抵は突破できるだろう。

さらに、フォームのソースからhiddenで送信されている値を読み出して同じように送信してやれば、大抵のcgiプログラムは正常動作するだろう。ただし、正常動作したところで、意図した宣伝効果が得られる確証はない。確証がなくても、1%でも意図した結果が得られれば、広大なネットの全体に放たれたspam書き込みプログラムは膨大な数の宣伝を実現することができるはずだ。

こんなやり方が広まってしまうと、ネット上のcgiなんてもうほとんど使いものにならない気がする。

ネット上で、自由に書き込めるプログラムがあればなんでも勝手に書き込まれてしまうし、掲示板のようなものではなくて、何かの処理を行うようなプログラムがあれば、それらは意図しないタイミングで起動される恐れがある（そんなケースがあればセキュリティ的によろしくないけれども）。

ユーザー認証とか、画面上に画像で文字を表示して「この内容を入力してね」なんて操作をユーザーにさせることによって、この手の書き込みを防ぐ技術があるが、それはユーザーに負担を強いることであり、ある意味spamに敗北していると言えなくもない。

今来ているようなものであれば、どうにかユーザーに負担をかけずに対策できなくもない。しかし、段々エスカレートするにつれて、私は暗澹たる気分になってくる。

ネットワークの未来は一体どうなるんだろう。
誰にでも開放されていて、誰でも発信できる時代は一時的なもので、もしかしてもうそろそろ終わってしまうのだろうか。そこまで考えるのは考えすぎだろうか？でも私は考えてしまう・・・

昨日の掲示板SPAM対策のログを調べてみた。
やっぱり、俺を一番悩ませていた「色んなURLを大量書き込みしてくるやつ」が4件ほど釣れました。全てがURL書き込み件数のチェックで引っかかってます。

URLの書き込み件数超過チェックに引っかかるってことは、もう一つ仕掛けた「パラメータの変更」は突破しているということで、まさか人力か、そうでなければHTMLのフォームをわざわざ解析して送信している（解析したって限界があるから、これをわざわざやるとは考えにくい）可能性がある。

具体的に変更したパラメータというのは、うちの掲示板に使っているyy-boardの「mode」というパラメータの値である。
この手の掲示板cgiというのは、ひとつのcgiで記事閲覧から書き込み、さらには記事削除と様々な処理を行うケースが多いので、この「mode」のように何らかの形で処理モードを渡して処理を切り替えているものが多い。今回やったのは、書き込み時に設定される処理モード「regist」を別の文字列に書き換え、それまでの「regist」では書き込みが行われないようにした、という対処方法である。

ほとんどの場合の書き込み自動化プログラムは相手のCGIの仕組みに合わせて固定的に作られる（はず）ので、yy-boardが相手なら書き込み時には「mode=regist」の値を送信するように作るはずである。これでネット上にあるyy-boardのほとんど全てには書き込めるはずで、今回のSpammerのような悪意のあるプログラムでなく、単純に掲示板のビューアとして動作するソフトウェアなんかも存在する。

この固定的なアプローチが通用しない場合、書き込みの自動化は非常に難しい。HTMLで書かれたフォームの意味を動的に解釈することなど（あてずっぽうでもなければ）不可能だからだ。

厳密に言えば、今回変更したのは「mode」というパラメータ名ではなく「mode=regist」として表現される「regist」という値だ、という点が対策としては若干手抜きと言える、yy-boardというプログラムのルールにおいては「mode」は処理モードなので、正規の投稿フォーム画面を読めば書き込み画面が「mode」に何を設定しているかはある程度は解釈可能である。

しかしそんなことをやるメリットが思いつかない、そんな乱暴な対策を取るサイトがそんなにたくさんあるとは思えないからだ。となると他にこの対策を突破する方法は「人力書き込み」という最強の方法がある、制限しきれない様々なIPアドレスからアクセスされれば正規ユーザとなんの区別もつけられないからこのレベルでは対策しようがない。

でも、それはふつーに考えてやらないよな・・・
そりゃ、物価の安いどこかの国ならn件で10円とかでも喜んでやる人達がいるかも・・・とか恐い想像もできなくはないけど、それは恐いから想像したくない（笑）

というわけで、一体どうしてあの対策を突破してくるのかいまいち解らないのだが、突破してくるやつに対してはURL書き込み件数のチェックで弾けているので当面は問題ない。パラメータの変更によって弾いた例は現段階ではまだログに出ていないが、これも近いうちに出てくるんじゃないかなーと思う。

ところで、今回探してみたら、SPAM対策済みの掲示板スクリプトっていくつか配布されてました。これ使えばよかったのかな（笑）

いちお、前のバージョンの掲示板が独自に改造してたこともあって、その改造コードを移植するよりはと思って自力で対策したんですけれど、先日掲示板を新しいバージョンにした時にどのみち改造コードの移植はやってしまったので、これははっきり言って無駄にコードを書いてしまったということになる。プログラマとしてはあまり感心できないことである。

書く前にちゃんと探しましょう（笑）

さてさて、掲示板SPAM対策、色々やってたんですが、今日掲示板を見て愕然としました。

なんか、多種多様なURLがどっさり書いてある。

50件以上は書いてあっただろうか、これじゃ他の記事が読めないし・・・
これだけ多種多様にURLを書かれてしまうと、書き込み禁止ワードにどのURLを設定していいものやら解らないし、設定したところでまた新しいパターンが登場すればそれまでです。

さあ困った、どうする？

そこで今回は、本文中に書き込まれるURLの件数を制限するチェックを追加しました。URLが6件以上検出されるとエラーを返して書き込みを止めます。
相手が人力かつやる気まんまんな相手の場合、ひとつの書き込みを5件以内に分割して大量書き込みなんてこともあるかもしれませんが、恐らくそこまではやらないでしょう。

また、最近2chみたいにttp://でURLを書いていくタイプもあったので、ttp://の場合もばっちり捕まえます。

それから、大量にURLを書くわけではなく、一件か二件くらいしか書かない代わりにエロ宣伝文句満載のSPAM書き込みも最近増えてきてます。こいつが手動なのか自動なのかは解らないですけど、手動書き込みのパターンがあったとしても必ず自動で書き込んでくる奴もいるはずなので、先日のバージョンアップした時に元に戻っちゃってた、フォームパラメータ名の変更も再度やってみました。

同じCGIスクリプトを狙って自動化された書き込みの場合は、これですっかり止められるはずです。

また、今回、それぞれのチェックに対して、実際にチェック処理にひっかかってエラーを返した際にログを記録するようにしました。これで、実際に効果があったのかも含めて把握できるはずです。その報告もここのブログでやっていきたいと思います。

ある程度効果が上がったら、掲示板SPAM対策まとめサイトでも作りましょうか。プログラムを直接改造するタイプの対策を挙げているサイトはあまりなかったようなので、これはこれで意味があるかもしれませんね。

結局、掲示板CGIを新しいバージョンに変えて（ちょっと機能追加してたから大変だったけど）、そいつについてた「禁止ワード検出機能」を使って宣伝されるURLを禁止して対策完了としました。

禁止ワードに追加しなきゃいけないと対応が常に後手に回ってしまう危険はありますが、相手は宣伝するURLが書けなきゃ意味がないので、まあ対策としては有効です。

ついでにソースを眺めてみたら各種いたずらに対する対策も強化されていたようなので、まあよかったかなと。

ひとまずこれで対策完了とします。

最近本家サイトの掲示板がうるさいのです。
三時間間隔くらいで広告書き込みが来まくるんです。

色んなIPアドレスから来てるのでアクセス制限もし辛いし。

なんか対策ないかなーと思って調べてみても「警告の文章を書いておく」とか無意味そうな対策が書いてあったりしていまいち求めるものに出会えませんでした。

アクセスログを見ると・・・

1.目的の掲示板にアクセスする
2.書き込みを行う（1のReferrerをつけて）

という順序になっている、警告書いておくって対策が出てたり、1の手順が含まれていることを考えるとまさか人力か？とも考えてしまうが、やはりこれは自動化されたプログラムによる投稿だろうと思うので、CGIに細工してみた。

フォームから送ってくるパラメータ名をちょっと変えてしまっただけなんだけどね。

使っているのが沢山出回ってるフリーウェアの掲示板だから、それに合わせた内容を書き込んでいると思う、であれば、それを変更してしまえば、プログラムからは正しい書き込みができなくなるはず。

で、掲示板の本来のユーザーは画面のフォームに従って投稿してるわけだから、影響は受けない。一部、Web上の掲示板を巡回するツールもあるけど、うちの掲示板でそんなの使う奴もいないだろうからそれらは放置です。変更内容を公開すれば設定で対応することもできるだろうけど、それもめんどくさいので要望がない限りはやりません。

とりあえず、人力でなければこれで対策できるはずなのです。
昨日の夜に対策して、今朝までとりあえずSPAM書き込みはありません。

ただ、ネット上を調べてみると、書き込み中にURLが含まれていたら弾いてしまえ、とか、どうも人力を意識して対策してるような例がいくつか見受けられるのでなんか不安です（笑）

人力だと本来のユーザーの書き込みと完全に区別するのって不可能に近いしね・・・本来のユーザーにはちゃんと書き込みできる環境を提供しないといけないから、区別ができなくなったらそこでアウトなわけです。まさかそんなことはないと思うけどな（笑）

人力ならあんな寂しい掲示板に書くのは労力の無駄だと思う（笑）

でも、パラメータの変更なんて誰でもすぐ思いつきそうな手段が他に見つからなかったって事実が俺をちょっと不安にさせてるのです。まあ、今日一日様子を見てみよう。

やったことないんですよねぇ・・・
なんせいつも「とにかく君はJava書いてJava教えて、他にJavaできる人いないから」ってプロジェクトばかり転々としてきたせいか、データベース周りはほとんど触ってない

そーいう時は、決められてきたものに従って作っちゃえばまあいいんですけどねぇ・・・

自分のサイトのテーブル構成をまじめに作り直そうと思って悩んでます。

今の構成は正規化すらサボってるので絶対人に言えません（笑）
で、俺のサイトってのがこれ

http://j-world.nu/

詩が投稿されてきて作者別にまとめられてて感想つけられますよーって作り。

単純に考えると

作者
作品
感想

の3つくらいに分けて考えたらいいんだよなー、くらいまではわかるんです。
が、たとえば・・・
http://j-world.nu/servlet/do/viewer?id=4305&poet=343
こんな風に、感想何件ついてますーとか表示したら、作品と感想のテーブルから取得しなきゃいけない、まあもちろんSQL的には一緒に取れるますし、この程度ならまあいいやって気にもなるけど。

http://j-world.nu/index/poetsindex.html

例えばこんなばかでかいリストになるとどうしたものか・・・作者名は作者のテーブルが持ってますし、作品数と最終更新日は作品のテーブルから求められます。
※テーブルの詳しい内容を説明してないから説明不足かもだけど

http://j-world.nu/system/poetinfo.cgi?POET_NO=0343

さらにこっちまで行くと、作者と作品と感想それぞれ読まないといけません、もちろん、SQL使い慣れた方ならそんなもんどうってことないんでしょうけど、そもそもうちのレンタルサーバがMySQL3系なので凝ったクエリーが非常に書きづらいし、俺はSQL使いとしては低レベルなのでいまいち自信が持てません。

例えばこれで、作品のテーブルにその作品への感想総数（と感想の最新日付）のカラム持ったりとかって、アリですかねぇ？

当然、感想書くときに作品のテーブルを更新しないといけなくなりますが・・・

設計としてクリーンなのはあくまでそれぞれのテーブルから必要な値を求める。って形だと思うんですけど、このあたり柔軟に曲げてしまうのってアリなんでしょうか？

もちろん、それぞれの画面へのアクセス数とかから負荷を考慮して、その上でどうするか、って考え方もあると思うし、実のところ負荷的に問題になるようなアクセス数なんてないんだけれど（笑）

いや、誰に聞いてるんだよって気もしますけど（笑）

mixiで同業者さん達にも公開されてるし、Thunderbird記事のおかけでたまに検索してここにたどり着いてくれる人とかもいるから、もしかしたら誰か・・・と思って書いてしまってます（笑）

もしも誰か気が向いたら話を聞かせてください（笑）

いやぁ、チャットに取り付けたAjaxもどきな参加者カウント機能、うっかりしてIEでのテストしてなかったよ（笑）

IEでやったら二回目以降が動いてないでやんの（笑）

詳しく調べなかったけど・・・なんだろ、キャッシュでも参照してるのか、リクエストの呼び出し自体は成功しててもサーバに呼び出しが来てなかった。

対応策も詳しく調べてないんだけど、メソッドをGETからPOSTにして、なおかつ今までnullを渡してたsendに対しててきとーに文字列投げたら無事に継続して動くようになった。

これ、人によってはハマっちゃいそうなトラブルだから、ここに書いておく意味はあるかもね。

ついでに、サーバへの呼び出し間隔を3分からさらに広げて10分にしときました。onunloadによる参加取り消しの通知に失敗すると、最大で10分間幽霊が残ることになりますが、そんなに沢山人が来るサイトじゃないから10分なんてどうでもいい数字です（笑）

さて、そういうわけで前の記事の後ろで心配していたCGIの呼び出し間隔をさらに広げて3分間隔にしてみました、まあ、大した差はないですがこのくらいなら参加人数の少ないうちのサイトではまったく問題ないレベルです。

でもさ、ちょっと考えてみたのですよ。

今回はAjaxと呼ぶにはあまりにも中途半端なプログラムなのでサーバー側へのリクエスト送信の回数がだいぶ少ないですが、普通にAjaxっていうと、もっと頻繁にサーバにリクエスト投げるほうが多いんじゃないかと思います。Google Mapsなんてレスポンスの容量も半端じゃないレベルだよね。

いや、もちろんそんなに頻繁に投げなくてももっとゆったりしたAjaxというのもありえるとは思いますけれど。

恐らくはサーバへの負荷を考えてのことですが、私の使っているレンタルサーバではウェブチャットの設置が禁止されています。

でも、Ajaxって使い方によってはウェブチャットをはるかに超える高負荷になるだろうことは想像に難くないですよね。

やがてはAjax禁止を明記したレンタルサーバってのも出てくるのかなぁ、とちょっと思った。

うちのサイトのチャットをちょこっと改造してみました。
とはいうものの、チャット自体はレンタルのJavaアプレットなので、あのプログラム自体は俺が直接手を入れることはできません。

そこで、あのチャットの置いてあるhtmlファイルの方に細工したわけです。
詳しくはソースを見てしまえばわかりますが、あのファイルを読み込むとonloadイベントでXMLHttpRequestを使用して、うちのサーバ上のCGIを呼び出します。
CGIは単純に、呼び出された時間とIPアドレスをファイルに記録します。そのときファイル中に記録されたレコードの中で、一定時間（今のところ130秒）を過ぎたレコードがあれば削除されます。
また、onloadイベントのイベントハンドラではsetTimeoutを使って一定時間（今のところこっちは120秒）ごとに同じCGIを呼び出します。

ウェブチャットなんかでよくある、入室者の管理ですね。
ただ、入退室を検出できるのはアプレットのみなので、入室していないROMのメンバーも同じようにカウントせざるを得ません。それでも、トップページを見ただけで、今チャットを見てる人がいるってことがわかれば、チャットに入ってみようかなって気にもなりやすいでしょ？

JavaScriptが動かない環境とかでは動作しないわけですが、元々この手のプログラムはそんなに精度が高い必要はないので気にする必要はありません。

そして、サイトのトップページではSSIを使って、ファイルに記録されたIPアドレスの中から一定時間（書き込みの時と同じ130秒）を経過していないものの数をカウントして、現在の参加人数としてトップページに表示します。

ついでにonunloadイベントも捕まえて、こっちでもやっぱりXMLHttpRequestを使用します。こっちでは自分のIPアドレスが記録されていれば即座に削除、ということをやって、退室者の処理とします。

まあ、unloadが取れるなら定期的にCGIを呼び出し続ける必要なんてないのでは？とも思うわけですが、手元のFirefoxでは他のページに遷移させる場合はonunloadが動いたものの、ブラウザを閉じる場合には動かないことがあるようでした。

onunloadが動作し損ねると、ずっと参加者がいるまんま、ということになってしまいます。

それではまずいので一定時間を経過した参加者を除外するわけですが、除外するのなら定期的に参加を確認しなければいけません、このあたりの考え方自体は昔からウェブチャットでやっている考え方と一緒ですね、必ず退室ボタンが押されるとは限らないので定期的に入室者を管理しなければならない、という。ウェブチャットの場合はログのリロードがあるのでそこに混ぜ込めば済んでしまいますが。うちのシステムではチャット本体は別のプログラムなので入室者管理専用にプログラムを呼び出さなければならないという。そういう話です。

というわけで、今回初めてXMLHttpReauestを使ってみました。

レスポンスの処理すらしていないので、これをAjaxと呼ぶのは無理があるでしょう。実際にはAjax（Asynchronous JavaScript and XML）といってもXMLを使用しないケースは多いようですが、レスポンスをまったく処理しないというのはさすがに違う気がします。

でも、とりあえずリクエストの送信自体は実に簡単に楽しく作れましたよ。

今回の機能、問題としてはウェブチャットと同じように定期的にリクエストを飛ばさなければいけないのでサーバの負荷が心配になりますが、ウェブチャットのようにログを取得したりしているわけではないので、転送量的には多少マシだと思います。さらには、参加者数を把握するだけなのでそんなに短時間に頻繁にリクエストを飛ばす必要もなく、現在設定した120秒ってのは標準的なウェブチャットのリロード（30秒くらい）の4分の1の頻度ですから、まあマシだとは思います。

とはいえ、ほとんどの場合onunloadで退室を検出できるならば、呼び出しの間隔はもっと長くてもいいかもしれないと、これを書きながら思いました（笑）

んー・・・あとでもうちょっと長くしときます（笑）