National Science Foundation (米国科学財団) は 1994年、インターネット上での商用宣伝の禁止を解きました。その当時は E メールと Usenet が主な通信手段であり、Gopher などの単純な公開システムが、より広範なユーザー・ベースを確立しようとしていました。Web はようやく生まれたばかりでした。その年、Canter & Siegel という法律事務所が Usenet 上に初めて大量の商用スパムを送り込みました。彼らは自分達の行っていた「グリーンカード抽選」サービスの広告を Perl プログラマーを雇って生成し、そしてその広告を 6,000 を超えるニュースグループにまき散らしたのです。彼らは有名になると同時に悪者にもなりました。そしてすぐに他の会社のためにスパムを作成する会社として、スパムのメリットを宣伝し、また「インターネット・マーケティング」の本を執筆するビジネスを開始したのです。それ以来、不適切な商用広告と無縁のオンライン・フォーラムはなくなりました。オンラインでの議論の場として Web が一層重要になるにつれ、また Web 2.0 の手法によって人々は Web を読むのと同じように Web に書き込めるようなった見返りに、スパムの問題が大きくなっています。

Web スパムは些細な迷惑にすぎないこともありますが、悪質な問題であることの方が多いものです。スパマーは多くの場合、1 つか 2 つのメッセージを投稿するだけでは満足せず、膨大な量のメッセージをフォーラムに送り付け、フォーラム本来の主題を圧倒してしまいます。スパムには場合によると、フォーラムに参加する気がそがれるようなポルノや反社会的なメッセージが含まれていることもあります。ほとんどの検索エンジンはそうしたメッセージが含まれるページやスパムと関連するサイトへのリンクがあるページのランクを下げますが、これはスパムが検索エンジンの最適化を妨げる可能性があるということです。そして最後の被害として、Web 公開者はスパムとの戦いにリソースを浪費する羽目になり、他の作業のための時間を取れなくなってしまいます。

• Web スパムには、次のようなさまざまな形式があります。
• ウィキに対するスパム記事や妨害記事
• ブログに対するコメント・スパム
• フォーラムや issue tracker、その他議論のためのサイトへのスパムの投稿
• リファラー・スパム (スパム・サイトが、リファラーを表示できるターゲット・サイトのユーザーを装う)
• ソーシャル・ネットワーキングで偽のユーザーとしてエントリーする

Web スパムへの対応は非常に困難ですが、スパム防止を考慮しない Web 開発者は自分を危険にさらすことになります。この記事と次の第 2 回では、多くの種類の Web スパムに対抗するための手法や技術、サービスについて説明します。

スパマーの振る舞い

人々がオンラインで貢献する場合の時刻やその内容は一定ではありません。スパムは一般的にプログラムによって作成されます (例えば Canter & Siegel のために Usenet の 6,000 のグループに投稿を行った Perl スクリプトなど)。場合によると、これらのプログラムの機械的なパターンを活用することでスパマーに対抗することができます。例えば登録が必要な場合には、さまざまな警告サインを使うことにより、さらに調査が必要なアカウントであることを示すフラグを立てることができます。もし、そのアカウントが最上位レベルのドメイン (.ru、.br、biz など) のものであれば、そのアカウントはスパマーと関係している可能性が非常に高いと言えます。フラグが立っているアカウントに対しては、そのアカウントによる最初のいくつかの投稿を保留にし、それらの投稿を調べてから保留を解除するのです。

フラッド制御

ウィキやブログ、フォーラムなどへのスパマーは多くの場合、何秒かの間に何十件ものリクエストを送信します。そこで、ある一定時間内に 1 ユーザーまたは 1 つの IP アドレスから送信できるリクエストの数を制限することで、少なくとも被害を抑えることができます。この手法はフラッド制御と呼ばれています。この方法を利用して、1 つのページだけではなく必ずサイト全体にわたってリクエストを制御する必要があります。

振る舞いを評価するためのこうした手法や、次のセクションで説明する他の手法を適用することで、スパム以外のタイプの Web 上の妨害を防ぐことができます。例えば Web メール・サービスをホストするサイトに対して、スパマーは大量にアカウントを作成し、そこからスパムを送信しようとするかもしれません。あるいはオンラインのオークション・サイトをホストするサイトに対して、オークションのプロセスを操作するプログラムを作成する人がいるかもしれません。一般的に、新しいユーザーを登録するためのシステムであればどこであれ、一部のユーザーは自動的な登録方法を見つけて有害な目的を果たそうとする可能性があります。一般的に、ここで説明する手法を利用することで、その Web サービスを利用する人達の素性を確認することができます。

ワークフロー制御

大部分のスパムはロボットから送信されます。ロボットがサイトを使う場合、その使い方には特徴的な癖があるため、その癖を活用することができます。図 1 は、サイトに追加するためのメッセージやコメントを送信する際について、人間による典型的なワークフローとロボットによる典型的なワークフローの違いを要約したものです。

ロボットによる典型的なワークフローでは直接 POST リクエストに進むため、これを検出することで大量のスパムを阻止することができます。

フォームを変化させる

リクエスターに対して行う最初の質問は、メインのフォームはリクエスターがロードしたものかどうかというものです。それをチェックするための 1 つの方法として、フォームのさまざまな側面を (ユーザーに対して) 見える形で、あるいは見えない形で変化させてみます。見えない形として通常使われる手法では、フォーム・フィールドの名前を変化させます。例えば日付やユーザー IP、その他のベースに対する修飾子を変更したものを使ったフィールド名 (content_081010_68_45_76_45 など) を持つテキスト領域を、メイン・コンテンツと共に 1 人のユーザーに送信します。変化するフィールド名を再利用してはいけません。また目に見える形で変化させる方法として、例えば使用されている IP が他のパターンから見て疑わしいと思える場合、投稿する際にボックスにチェックを入れるように一部のユーザーに要求する方法もあります。

ナンス・テスト

ナンス (nonce) は推測が困難な値であり、フォームを含むページを表示するたびに生成されます。そしてフォームを送信する際に、フィールドの 1 つとしてそのナンスを要求するのです。ロボットがフォームを送信してから直接 POST に進む場合には、そのロボットは HTML ページをロードしていないため、期待されているナンスの値を知りません。ナンス・テストの詳細を調整する方法は数多くあります。どの場合においても、絶対にナンスを再利用できないようにする必要があります。そうしないとスパマーがこの方法を簡単に回避してしまいます。ナンスの生成と検証には、ページ・リクエストが行われた IP アドレスと日付または詳細な時刻を使う必要があります。

JavaScript の検出

一部のロボットは、ページをロードしてナンスを読み取ることでナンス・テストをくぐり抜けようとします。不注意なスパマーであれば、必要な情報を入手できたら即座に POST を送信するようにロボットを動作させてしまうかもしれません。フォームがロードされた直後に、人間がフォームに入力したとは思えないほどすぐにフォームが送信された場合には、フラグを立てる必要があります。これはフラッド制御テストと関連しています。ロボットがもっと注意深い場合であっても、ロボットはフォーム・ページでは何も JavaScript を実行させないことが多いものです。これをいくつかの面に活用することができます。まず何よりも、フォーム・ページの実際のコンテンツの中でナンスを生成してはならず、フォーム・ページからの JavaScript による 2 次的なリクエストの中で生成する必要があります。ユーザーがメインのコンテンツ・フィールドにデータを初めて入力したときにイベント・ハンドラーを設定するようにします。図 2 はこの方法を示したものです。

この方法の大きな問題は、一部のユーザーは JavaScript を無効にしていることです。また実際、一部の会社ではポリシーとして JavaScript を無効にすることを要求しています。そのため、ユーザーが自分自身を認証できるように、2 次的な方法を提供する必要があります (例えば、JavaScript を呼び出さないユーザーに対してのみ、変化するフォームを使用する、など)。またその一方で、一部のスパマーはブラウザー・エンジン内部でスクリプトを使って攻撃を起動するため、彼らは実際に JavaScript を呼び出します。JavaScript テストは、絶対的な決定要素として使うよりも、スパムを検出するための重み付け要素として使う必要があります。

人間的要素をテストする

Web スパムに対抗するために非常によく使われる方法の 1 つにナンス・テストの変形版があります。これは、大部分の人間にとっては容易でありながらロボットにとっては困難な何らかの視覚的なテストを投稿フォームに含める方法です。そうした方法として最もよく使われるものが CAPTCHA です。このテストでは、英数字による何らかの文字を表す画像をユーザーに表示し、ユーザーはそれを読み取ってフォーム・フィールドに入力する必要があります。スパマーは OCR (Optical Character Recognition) を使って CAPTCHA を克服しようとするため、通常は画像が大幅に歪められています。図 3 は CAPTCHA 画像の一例です。

この例のように画像が少し歪められていても、スパマーはこうした CAPTCHA を克服できてしまうため、彼らに対抗するために、より一層歪んだ画像が使われるようになっています (図 4)。

ここにはいくつかの問題があります。第 1 に、スパマーに対抗するために CAPTCHA をより一層歪めると、人間にとって読みにくくなります。また視覚障害者など一部の人は CAPTCHA 画像をまったく見ることができないため、この手法はアクセシビリティーを制限してしまい、また一部の状況では違法とされる場合さえあります。そうした困難にもかかわらず、CAPTCHA はスパム防止用に最も一般的に使われる手段になっています。

テキストを確認させる

上述の手法と似ていながらアクセシビリティーの問題を起こさない手法として、ランダムなテキストによる質問をユーザーに対して表示する手法があります。対象のサイトが特定のドメインを持つ場合であれば、質問の中でそのドメインに関する基本的な知識を要求するのです。例えば医療関係のニュースや情報のサイトでは、「呼吸に係わる主な臓器は何か (What is the primary organ associated with breathing?)」のような質問をし、「肺 (lungs)」という答えが返ってくることを確認します。この手法では、そうした質問として多種多様なバリエーションを用意し、また人間であれば普通に答えられてもロボットでは通常は推測できない言葉を使うように注意することが重要です。

上に戻る

まとめ

この記事で説明したすべての手法には、投稿する人がその投稿をプレビューするように強制することで、細かな調整を追加することができます。この余分なワークフロー・ステージを追加するだけで一部のスパマーを捕らえることができ、またこれを注意深く行えば (例えば JavaScript を使うことで一部のユーザーにはプレビューを自動化するなど)、投稿する気が失せるほど投稿が面倒になることはないはずです。CAPTCHA や、フォームの変形操作、ナンスなどをワークフローに応じて適用することで、悪意のない大部分のユーザーが気付きもしない方法によってスパマーの作業を一層複雑にすることができます。

振る舞いを評価し、またワークフローを管理することはスパムを減らすには十分ですが、通常はスパムをなくすことはできません。例えば一部のスパマーは、この記事で説明したすべての制御を回避するために人を雇います (彼らによる操作は「mechanical turk (人間による知性を必要とする単純作業)」攻撃と呼ばれることがあります)。彼らは人件費が安い場所で賃金を払って人を雇い、ターゲット・サイトに行って手動でスパム・メッセージを残す作業をその人達にさせるのです。mechanical turk や高度なスパム・ロボットに対抗するためには、皆さんと同じようにスパムを憎む人達による大きなコミュニティーの力を活用する必要があります。このシリーズの次回の記事では、その方法を説明します。

参考文献

学ぶために

• (読むに耐えないかもしれませんが) スパマーのパイオニア、Canter & Siegel についての説明を読んでください。また背景情報がスパムの記事に説明されています。
  
  
• CAPTCHA に関するウィキペディアの記事には、CAPTCHA の歴史やバリエーション、実装方法などが説明されています。
  
  
• ブログでのスパムに関するウィキペディアの記事には有用な情報が豊富に集められています。
  
  
• ブログやフォーラムのソフトウェアを開発する人達の多くはスパムに対抗するための優れたリソースのページを持っており、その一例として Six Apart (MovableType のメーカー) や Wordpress などがあります。
  
  
• David Mertz 著の「Charming Python: Beat spam using hashcash」を読み、E メールだけではなくウィキなどに対するスパムを最小限にとどめるための hashcash 手法について学んでください。
  
  
• developerWorks の Web development ゾーンに用意された、Web 技術に特化した記事やチュートリアルを利用してサイト開発のスキルを磨いてください。そこにはこのシリーズのこれまでの記事も含まれています。
  
  
• developerWorks technical events and webcasts で最新情報を入手してください。
  
  

議論するために

• developerWorks blogs から developerWorks のコミュニティーに加わってください。
  
  

著者について

Uche Ogbuji は次世代の Web 技術によるソリューションを専門とする会社 Zepheira, LLC のパートナーです。Ogbuji 氏は XML、RDF、およびナレッジ・マネージメント・アプリケーション用のオープンソース・プラットフォームである 4Suite とその後継である Akara の中心的開発者であり、またチームによる Web 開発のための Jacqard アジャイル手法、そして Versa RDF 問い合わせ言語などの開発リーダーでもあります。彼はナイジェリア出身のコンピューター・エンジニア兼ライターとして米国コロラド州ボルダーに住み、そこで働いています。彼に関して詳しくは、彼のブログである Copia を見てください。

この記事を評価する

コメント

上に戻る

目次

• スパマーの振る舞い
• 人間的要素をテストする
• まとめ
• 参考文献
• 著者について
• コメント