* [spam] URI spamフィルタ (Part 1) とブロック機構: 概要 [#wb00d081]

- ページ: [[BugTrack2]]
- 投稿者: [[henoheno]]
- 優先順位: 重要
- 状態: 提案
- カテゴリー: 本体新機能
- 投稿日: 2006-11-18 (土) 23:48:10
- バージョン: 

#contents

** 関連: [#dc60ad85]
- [[BugTrack/772]] [SPAM] Wiki SPAMming
- [[開発日記/2006-11-04]] (official/dev) 内容ベースのspamフィルタ と 新規postについて
- [[開発日記/2006-11-12]] spam.php: 冒険者向け: 現状の組み込み手順
- [[BugTrack2/207]]: [spam] badhost: A list of URI redirection or masking services


** 修正 [#pd14f285]

- [[cvs:lib/spam.php]]

PukiWiki向けのspamフィルタのコンセプト実装について、実現している部分を中心に概要をまとめます。

+ ''URIの計測機構'' - URI追加型スパム(下記)の「ハイパーリンクを生成させようとする欲求の強さ(理不尽さ)」を計測します。
-- URIの直書きによる外部リンク生成要求の個数 (記法を問わない)
-- HTML Anchor タグ、phpBB BBCode ないしその派生記法による外部リンク生成要求の個数
+ ''上記フィルタを利用したブロック機構''
-- (comment、pcomment、bugtrack、trackerなど、特定のシチュエーションで)新規に追加されるメッセージを調べ、特定の条件でブロックする
-- ブロックされた側には、改行コード一つのみが送信されます。
+ ''ブロック内容の通知機構'' - ブロックした投稿内容については、ブロックした事がわかる形で管理者にメールされます。管理者は誤判定などが無いかどうか、ブロック通知をチェックすべきです。メールクライアントのフィルタ機構によって、普段とは別のフォルダへ振り分けることができます。
  Subjectの例 ('[blocked]' が挿入される):
  [PukiWiki] [blocked] 自作プラグイン/csv2newpage.inc.php


** 概要: URI追加型スパム [#a9766872]

他のWebアプリケーション(特に、第三者でも投稿できるHTMLフォームを持っているWebアプリケーション)に、URIを自動的に追加させようとするスパムを、ここでは「URI追加型スパム」と呼ぶ事にします。

このスパム行為の発信者には、ある程度明確な傾向があります。総じて、発信者は「(1)低コストで (2)大きな効果(※金銭的な)」をもたらすために、「(3)任意の外部へのリンク(HTMLのAnchorタグ)を (4)ある程度の期間 (5)対象のサイトに出現させる/消させない」という事に強いモチベーションを持っています。


*** URIに関する工夫 [#l00a18d6]

単純な(文字列比較や、正規表現による)フィルタを回避できるように、URIには、防御側が想定しないであろうバリエーションを持たせる事があります。例えば語句のゆれを作成するために無駄な要素を追加したり、通常存在するべき要素を削ったり、大文字/小文字やpercent-encode の有無を変化させることがあります。

  単純な例: メッセージとURI
  buy foobar http://example.org/buy/foobar
  buy foobar http://example.org#buy_foobar
  buy http://victim.example.org/go?http%3A%2F%2Fnasty.example.org
  order foobar HTTP://EXAMPLE.ORG/BUY/FOOBAR

URIに使用されるドメイン名にはいくつかの傾向があります。
- 既存のサイトの一部 (サブドメイン・ディレクトリ) を借用したもの
- レンタルWebスペースやブログレンタルサイトのようなサービス(サブドメイン・ディレクトリ)を借用したもの -- もちろん複数アカウントによって複数個が利用される
- 独自にスパム用のドメインを取得したもの -- ドメイン名は数字や文字の羅列である場合がある

いずれも、取得したドメインについては、(開設されてから閉鎖、ないし放置されるまで)ある程度の生存期間が存在します。


*** メッセージに関する工夫 [#d2d1dd0b]

ひな型と、その時追加したいURIを組み合わせ、生成したデータを投稿します。生成したテキストデータを投稿する場合と、ターゲットに選んだサイトから得た情報(例: どのようなフォームを持っているか)からひな型を作り、そこからデータを生成する場合があります。

特定の記法を解釈するWebアプリケーションを狙って、何らかの記法を利用する事があります。

  例: URIを(同時に)単一の方法で羅列
  [ url=http://example.org/buy/foobar]Buy Foobar[/url]
  [ url=http://example.org/buy/foobar]Buy Foobar[/url]
  [ url=http://example.org/buy/foobar]Buy Foobar[/url]

また、複数のWebアプリケーションでも(羅列したURIの)どれかが外部リンクとして成立する様に、複数の記法をミックスさせる事があります。

  例: 同じURIを(同時に)複数の方法で羅列
  Nice site!  Check about foobar
  http://example.org/buy/foobar
  <a href=" http://example.org/buy/foobar ">buy foobar</a>
  [ url=http://example.org/buy/foobar]Buy Foobar[/url]

AnchorタグやBBCodeなどの記法を用いたuri spamの特徴としては、「記法に関してはほぼ正確である」という点があります。この点については、それぞれの記法を解釈できるサイトについて、間違いなく記法を解釈させるためであると考えることができます。
 <a href= http://example.org >buy example</a>    <= "</a>"で閉じている
 <a href="http://nasty.example.com">visit http://nasty.example.com/</a>
 <a href=\'http://nasty.example.com/\' >discount foobar</a>
 [ url]http://nasty.example.com/[/url]
 [ url=http://nasty.example.com]visit http://nasty.example.com/[/url]

ターゲットとしたサイトごとに適切な記法を使わない点については、投稿側のスパム作成コストや、スパム対象一覧の蓄積方法・流通方法などに原因があるのではないかと推測する事ができます。もしそれに見合うのならば、適切な内容が使用されるでしょう。


*** 自動投稿に関する工夫 (対象、頻度、分量に関する工夫) [#t71f3a46]

着実な積み重ねによって、ターゲットとしたサイトを侵食する事を目標とします。結果的に、管理側が長期間にわたり管理を放棄した状態となるのが理想的です。

例えば:
- プログラムを使ってスパムを投稿させます。
-- 投稿対象として認識したサイトは次回以降も活用します。
-- ターゲットのサイトの大元(ネットワークプロバイダ)や、発信側のネットワークプロバイダ等から締め出されるほどの頻度や量では活動しません。しかし人間にとっては充分に高頻度(数分~数時間等)に、かつ長期間に渡り、昼夜休まず投稿を行います。
- 管理側へ対策として:
-- データの量や頻度を非常に大きくする事があります。
-- 管理側に気付かれないようにURIを追加する方法があるならば、それを試みます。
-- 複数のIPアドレスから投稿を行わせます。
--- 異なるIPアドレスからのリトライ、ないし多重投稿を行わせる事で、フィルタの貫通性能を高める事があります。
--- 一度利用したIPアドレスは数日~数週間後に再利用する事があります。(※送信側のコストの都合による)
-- 投稿した内容が掲載されているかを確認し、異常があれば確認します。例えば、投稿用のIPアドレスの一つから、URIを含まないデータが追加可能かどうかを確認します。


** URI追加型スパムのブロックについて [#d04277c7]

上記のような特徴をもっている自動スパムに対して、従来型の機械的なフィルタは、(1)ユーザーの利便性を損なわずに (2)管理者のメンテナンス負担を減らせるか、といった点のバランスに問題があります。

- IPアドレスによるブロック:
-- (静的) ホスト単位の拒否: 次からは異なるIPアドレスで投稿があるため、効果が薄い(例えば二週間後にやっと役に立つかもしれない)。またメンテナンスの負荷や頻度が高い。メンテナンス負荷を下げるための仕組みを導入すると、パフォーマンスが犠牲になりがち。
-- (静的) ネットワーク単位の拒否: 強いが、反動も大きい (利便性低下)
-- (動的) リアルタイムブロックリスト(RBL)の利用 -- 有効性と利便性の検証が必要。実行時にコストがかかる
- NGワードによるブロック:
-- 内容と、機能の柔軟性次第。また更新が必要 (メンテナンス負担増加)。単純すぎるNGワードは利便性を損なうか、損なうために追加できない。NGワードを追加しすぎるとメンテナンスコストは高まり、パフォーマンスが低下する。メンテナンス負荷を下げるための仕組みを導入すると、パフォーマンスが犠牲になりがち。

「URI追加型スパム」は、(投稿テストを除き)基本的に必ずURIをコンテンツに追加させようとします。そこで、投稿されるコンテンツに含まれるURIを検証し、その質や量で自動的にブロックを判定する機構があれば、IPアドレスが合致するかどうかや、NGワードを含んでいるかどうかに限定せずにスパムをブロックする事が可能になります。

--------
* コメント [#k68b8f3f]
- 追加のアイデアとしてもう一つ。発信者がスパムを登録する際、実際はblockされるんですけど、その後に、あたかも登録が成功したかのように振舞う仕組みを入れたほうが良いと思います。 -- [[teanan]] &new{2006-11-21 (火) 06:55:03};
- spam-botが登録後にリロードしてくるようになるだけの気もしますが、騙されるbotがいる事は期待できるかも。ただ表示内容を工夫しないと、万一誤判定が発生した際に分かりづらくなるかも。 -- [[にぶんのに]] &new{2006-11-21 (火) 23:48:49};
- 本当は一定時間維持できたら良いんですけど・・・。ますます誤判定したときに分かりづらくなりますが (^^; -- [[teanan]] &new{2006-11-22 (水) 02:12:04};
- 結果のあしらい方は内部の処理と独立しているので、表現方法は元々複数あると思います。他の方法も検討したりして、内部処理の話題とは個別に考えると話が進むと思います。このページは多分上の話でもっと長くなるので X) しばらくしたらページを分けるのが良いでしょう・・・・ -- [[henoheno]] &new{2006-11-23 (木) 00:46:06};
- 他の例: (1)即座に exit() する(最初こうでした)。 (2)即座に \n を返す(多分人間に優しいんじゃないかと思って・・・)。 (3) 人間にも機械にも判別できるメッセージを返す。(あなたbanされましたよ!) (4) とにかくでたらめな何かを返す(予測不可能にするのだけが目的。でも他のIPから確認すればバレる)。 -- [[henoheno]] &new{2006-11-23 (木) 01:01:24};
- N秒動作を停止する。攻撃側の足をひっぱるのかと思いきや、サーバー側のコネクション数などのリソースを浪費しかねないと思うのでご利用は計画的に。 -- [[henoheno]] &new{2006-11-23 (木) 12:11:33};
- 今最新のCVSでspam.php関連を評価させて頂いていますが、適用後に既存コンテンツに紛れていたSPAMを削除出来なくなりますね。editのPOST時に不可視のoriginalの内容も評価してしまうのが原因と思いますが、何とかなりませんでしょうか。 -- [[nobunobu]] &new{2007-01-01 (月) 22:10:41};
-- こんにちは :) 仰る通りで、現状は融通の利かない防御壁しかありません。既存のコンテンツにブロック対象があると、コンテンツがロックアウトされてしまうでしょう。特に badhost は強烈です(該当するURLが事前にあってはならない)。次に、HTML anchor = 0 なども同様です(該当パターンにマッチする会話があってはならない)。現状の基本的な回避策は、そのようなコンテンツがあったら、一旦条件を緩和して、(1)それが不必要なら削除する (2)それがパターンに合致しないように少し書き換える (3) それが問題にならない程度に今後もしきい値を緩和する 以外ないでしょう。 -- [[henoheno]] &new{2007-01-01 (月) 23:47:58};
--- 例えばそれが本当に不要なスパムの場合、仮にそのようなページがあれば、ユーザーにそのページを教えてもらって、管理者が個別にクリンナップをかけることができると思います。事前にそのパターンで既存コンテンツを検索しても構いません。一旦そのようなクリンナップが完了したならば、後は幸せになるでしょう -- [[henoheno]]  &new{2007-01-01 (月) 23:53:50};
-- 回避用のハックとしては、例えば、「とある IPアドレスからの編集についてはチェックしない」、といった事ができるでしょう。 -- [[henoheno]] &new{2007-01-01 (月) 23:53:10};
-- edit 周りの解決策としてはご指摘されている様に、現状のeditの機構そのものを見直す作業になると思います。originalの存在理由や、存在しなくても動いてしまう理由を問い詰めたり、修正内容の中から「追加される行」「削除される行」それぞれを取り出して評価する様な方向があると思います。ただ現段階のものは、過去バージョンのPukiWikiにも簡単に組み込ませられるような状況に持っていきたいと考えています。 -- [[henoheno]] &new{2007-01-01 (月) 23:56:54};
-- originalのcheckよけとして、function check_uri_spamの&br;foreach($target as $str) {&br;を&br;foreach($target as $key=>$str) {&br;&nbsp;&nbsp;&nbsp;&nbsp;if ($method['_comment']=='edit' && $key=='original') continue;&br;に変更するのはどうでしょうか?これならbadhostなURLを編集画面にて削除出来ると思いますが。 -- [[nobunobu]] &new{2007-01-02 (火) 00:04:31};
--- 'original' をチェック対象から外してしまう、というのはとても興味深いアイデアです :) 仮に実現するならどこでするかですが、lib/spam.php はあくまでも「一つの事をうまくやる関数」の集合体ですから、そこの check_uri_spam() に外部由来の例外処理を組み込むと、見通しが効かなくなると思われます。 spam.php に渡すデータを用意している段階 (lib/pukiwiki.php にある) でそれを行うのがよろしいかと思います。具体的には、$vars から 'original' を除いたものを作ってやればいいのだろうと思われます -- [[henoheno]] &new{2007-01-03 (水) 00:42:53};
--- ($varsの改変なんてやらないで)POSTされた内容として全てを保存したい(メールさせたい)場合は、$method を拡張する形で 「指定した array() の中にある $key と合致するものを検索対象から外す」機構を加える様にすると(original以外の用途にも使えるようになって広がりが生まれるので)良いのでしょう。 -- [[henoheno]] &new{2007-01-03 (水) 00:51:49};
--- 最大の問題は、'original' の有効性/無効性について確証を得ていない所ですね (^^; -- [[henoheno]] &new{2007-01-03 (水) 00:55:03};
--- いろいろとコメントありがとうございます。&br;とりあえず当方のサイトでは現状のCVSスナップショットに上記修正と別途RBL参照及びご認識よけホワイトリストを追加したもので、運用をはじめました。&br;適用数時間ですでに数件のBlockに成功しました^^&br;ほとんどが、#commentへのarea_anchorですけど・・&br;今暫定的に#comment機能を殺していますが、これであれば再開放しても良いかもしれません。 -- [[nobunobu]] &new{2007-01-03 (水) 01:35:02};
- JavaScriptにある乱数を生成させて、PHP側でも同じアルゴリズムで乱数を生成して、その2つを照合するみたいな。結局はAjaxになるんでしょうけど、未だにJavaScriptを解析できるBotは無いですし。 -- [[Logue]] &new{2007-01-16 (火) 22:50:01};

#comment

トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Site admin: PukiWiki Development Team

PukiWiki 1.5.4+ © 2001-2022 PukiWiki Development Team. Powered by PHP 5.6.40-0+deb8u12. HTML convert time: 0.065 sec.

OSDN