PHP 迷惑投稿対策 2021年06月30日 19:54   編集
スパム投稿対策研究のために設置した掲示板を長いこと放置していたら、スパム投稿でひどいことになっていた。対策は継続してやらないとダメのようだ。
旧掲示板のURLから今回新たに公開したbbs.phpにリダイレクトするようにした。PHP/掲示板PHP
  • ./yybbs/yybbs.cgi → ./yybbs/bbs/bbs.php
  • ./clip/clip.cgi → ./clip/bbs/bbs.php
できればスパム投稿を続けてもらって、bbs.phpがどれだけスパム防止効果があるか調べてみようということだ。とはいってもフォームから投稿してくるスパムはほとんど無いと思うので、これまでのスパムがすべて新掲示板に流れるわけではないと思うが。
・・・と思っていたが掲示板2の方はさっそく前の掲示板と同じ傾向のスパム投稿が来ている。JavaScriptのスライドロックも効果が無いので、ひょっとしたら人が投稿している?

bbs.phpのスライドロックは、ロボットはJavaScriptは無視するらしいということに期待して、JavaScriptで表示するロックを外さないと投稿できないという仕組みだ。ボタンを横にスライドするだけなので、読みにくい文字を入力したり、写真を選ぶ必要はない。この記事のテーマであるユーザーの負担が少ないスパム投稿対策というわけだ。続きを読む
counter:445
PHP 迷惑投稿対策 2020年03月25日 19:58   編集
Kent-Webのサポート掲示板で教えてもらったjQueryのslidelockというスパム対策機能を、この用語集作成PHPのbbsプラグインで使えるようにしてみました。→PHP/用語集作成
タイトル
投稿者
編集パスワード
コメント
添付
キーワード
  • Re:投稿者名 2020-03-25 20:03:02 MjI2YWEzM2  返信  編集
    >は太文字で表示するようにしました。
    投稿者を省略した場合、日にちとIPアドレスを元にした固有の文字列を表示するようにしました。
  • 投稿者名 2020-03-25 20:01:03 管理人  返信
    は太文字で表示するようにしました。
  • フォームを隠す 2020-03-23 11:32:49 管理人  返信  編集
    フォームを隠すオプションを追加しました。
    表示するかしないかの設定はクッキーに保存する仕様にしてみました。
  • 無題 2020-03-17 18:30:52 管理人  返信
    [[bbs('lock=1')]]と記述するとスライドが表示され、四角をスライドさせないと投稿ボタンが押せないしかけです。
counter:4,756
迷惑投稿対策 2017年05月22日 16:34   編集
Clip Board改造版のサンプルとして設置している掲示板に、また新しいタイプのスパムが来ているようだ。こちらも調査したい。
まだ投稿キーも搭載されていない頃のバージョンをベースに改造したものだったが、改造版投稿キーに入れ替えていたので、そこそこスパムはブロックできていたようだ。オリジナルのClipboardの最新版に更新した上で、URLを引き継ぐためにディレクトリ名とcgiのファイル名は以前のclip/clip.cgiに戻した。改造版の方もとりあえずディレクトリ名を変更して残しておくことにする。

掲示板(YY-BOARD)と同様に、ひらがなチェック、投稿IDチェック、ダミーフィールド処理を追加し、どの処理が有効かログを残すことにする。

掲示板2の方はアクセスが少ないが、投稿IDを送ってこないというタイプのスパムがいるようだ。これは初めてのケースだ。投稿キーはクリアし、スタイル指定で隠したダミーフォールドの値は送ってきているのに、hiddenを指定したinputタグに気づかないのも不思議だが、単純にオリジナル掲示板CGIで送られるはずの値を送っているだけかもしれない。
いずれにしても、新しいタイプではなく、むしろ古いタイプのスパムのようだ。投稿IDを送ってこないので、時間を計測する必要も無く、その時点で拒否するだけで済むので対策は簡単だ。
と思っていたら、掲示板の設定ミスで投稿IDがフォームにセットされていなかったことが判明^^;
ひらがなチェックや投稿キー、ダミーフィールドにも引っかからず、投稿IDだけで拒否していたスパムもあるようなので、気になる。ダミーフィールドに引っかからないということは、HTMLを見ていないという可能性も残っているが。

それと、フォームにアクセスせず、いきなり投稿してくるタイプがあることも拒否ログを見てわかった。

こちらの掲示板はスパム投稿の頻度は低いが、たまに来るものの中に投稿ID、ダミーフィールドどちらも突破してくるスパムがある。やはりJavaScriptを使わざるを得ないか。
counter:4,052
迷惑投稿対策 2017年03月24日 20:53   編集

リンク元 ユーザーエージェント

スパム投稿の動向を分析するためで環境変数でリンク元やユーザーエージェントをログに残してみたが、こうした情報もスパムかどうか判定するヒントになるかもしれない。
リンク元はPerlの場合、環境変数$ENV{'HTTP_REFERER'}で得られる。たとえばこのページのリンクから掲示板にアクセスしたら
http://shade-search.com/sts/term/term.php
がHTTP_REFERERになる。いったん掲示板を開いて掲示板の他のページから移動した場合は掲示板CGIのURL たとえば
http://shade-search.com/sts/fsw/yybbs/yybbs.cgi?type=2
のようなものになるはずだ。
この掲示板のURLをブックマークに保存していて、ブックマークから直接掲示板を開いた場合はHTTP_REFERERは空になるが、わざわざこの研究用掲示板をブックマークしているユーザーがそんなにいるはずはない。やたらリンク元なしや上記のtermやyybbs以外のURLから来たということになっているアクセスが多いが、ほとんどがスパムだと思われる。

より参考になるのは、フォーム表示時より、投稿時のHTTP_REFERERだ。
投稿するためにはフォームを表示しておく必要があり、正常な投稿ならまず間違いなくフォームを表示するCGIのURLになっているはずだ。ブックマークから直接投稿するということはあり得ないので、投稿時のHTTP_REFERERが掲示板CGIのURLになっていない場合はまずブロックして問題ないと思われる。
しかし、HTTP_REFERERはけっこう偽装してくるロボットも多いらしいので、逆に掲示板CGIのURLになっていても、本当にそこから投稿してきたかどうかはわからない。

ユーザーエージェントは$ENV{'HTTP_USER_AGENT'}で得られる情報で、ユーザーのOSやブラウザの情報が得られる。これはロボットだけでなくブラウザも偽装するものがあるので、情報としてはあまり当てにはならないが、空になっていたり、defaultなどとなっていたらあやしいといえるだろう。

全角チェック→ひらがなチェック

投稿内容に日本語が含まれていない場合、投稿を拒否するオプションが組み込まれている掲示板は多い。しかし言語によっては、文字化け部分が漢字になってしまって、日本語チェックを通ってしまうことがある。
この実験用掲示板では日本語チェックは
$in{comment} !~ /[\x81-\x9F\xE0-\xFC][\x40-\x7E\x80-\xFC]/
という正規表現でのチェックとなっていた。これは全角文字が含まれているかどうかのチェックだと思うが
Atenderemos su convocatoria lo m疽 veloz
posible, como encima, los avisos se pueden dar en cualquier momento, disponemos, a una parte
de nuestro servicio com佖, de un servicio de 24 Horas.
というような投稿は受け付けてしまう。こうした投稿も拒否するには正規表現を
$in{comment} !~ /([\x81-\x9F\xE0-\xFC][\x40-\x7E\x80-\xFC]){2}/
として全角文字が続けて2個以上含まれているかどうかチェックしたり、
$in{comment} !~ /\x82[\x9F-\xF1]/
として、ひらがなが含まれているかどうかのチェックに変更することによって、上記の投稿もブロックできる。
カタカナもチェックしてもいいのだが、カタカナだけの投稿というのも普通ないと思うので、いらないだろう。
この実験用掲示板の常連のひらがなタイトルのスパムはこのひらがなチェックをクリアするためのスタイルなのかもしれない。
日本人を対象とした掲示板なら、投稿内容にひらがなが含まれていないケースは少ないと思うので、
$in{comment} !~ /(\x82[\x9F-\xF1]){2}/
というひらがな2個以上チェックが有効かもしれない。

ちなみに上記の正規表現は文字コードがShift-JISの場合で、文字コードが変わるとコードが変わるので表記も変わる。
utf-8の場合は
'/[ぁ-ん]{2}/u'
のような表記でいける。
'/[ぁ-ゞ]{2}/u'
とする場合もあるようだ。この場合「ゔ」とか「ゝ」などの文字も対象になる。
utf-8の場合はuオプションが必要らしい。
Shift-JISではこのような表記を使うとエラーが出ので、コード表記にする必要があるらしい。

今後の予定

投稿フォームにアクセスしてくるスパムは、ブロックしたスパム投稿の何倍もありそうだが、あまり数が多いとこれもサーバーへの負担となる。ブロックされたスパムのIPアドレス、ホスト名はログに残しているので、こうしたアクセスは.htaccessでブロックしてしまえばWEBプログラムへの負担が少なくて済むのではないか。
deny from 91.200.12.119
deny from 91.200.12.149
のように書いてブロックすることになると思う。
同じホストで複数のIPアドレスを使っているケースもあるので、ホスト名で拒否する方法もあるが、そうするとWEBサーバーの負担が大きいらしい。
処理としてはスパムと判定して投稿を拒否した場合、IPアドレスが.htaccessの拒否リストに存在するかどうか調べ、存在しなければ追加するということになる。.htaccessは掲示板を設置したディレクトリに限定する必要は無いかもしれない。掲示板以外でもスパムにきてもらうメリットはないので、サイト全体のディレクトリに設置してブロックしてもいいと思う。
counter:4,920
迷惑投稿対策 2017年03月03日 21:03   編集
掲示板の迷惑投稿を防ぐ方法としては、ロボットではなく人が投稿していることを確かめるため、ロボットには読めないはずの画像による文字を読ませて入力させたり、複数の画像から質問に該当するものを選択させたり、掲示板に投稿する利用者に一手間かけさせるものが多い。
ここでは、なるべくユーザーに余計な手間をかけさせず、スパムを防止する有効な方法がないものか考えていきたいと思う。

投稿ID方式

フォームに隠しパラメータを仕込んでおいて、その値を送ってこない投稿は不正投稿としてブロックするという対策法は昔からある。しかしフォームのhtmlを解析しているのか、正しい隠しパラメータを送信してブロックを回避するスパム投稿は多いので、これだけではあまり効果のある対策とはいえない。フォーム表示のたびにランダムな値に変更しても同様だ。
しかし、最近これに投稿までの時間を計測して、あまりに早いものはスパムとして判断してブロックするという対策がどこかで紹介されていた。

なるほど、ロボットによるスパム投稿は大量の投稿をこなしたいはずなので、普通に人間が投稿するようにフォームを表示させ、名前やコメントをキーボードから打ち込んで投稿ボタンを押しているということはまず考えられない。フォームを表示しないかもしれず、したとしてもすぐに投稿しているとしたら時間計測によるブロックはけっこう効果があるかもしれない。処理としては、以下のようになる。

拒否処理

  1. 投稿フォーム表示する際、投稿IDを生成する。投稿IDはランダムな文字列で、input hiddenタグに投稿IDを表示し、同時に投稿IDが名前のファイルをサーバーに作成する。
    ファイルを開かなくても投稿IDが確認できるよう、テキストファイルに投稿IDを書き込むのではなく、ファイル名そのものを投稿IDにする。
  2. 投稿受付処理では隠しパラメータから送られた投稿IDに相当するファイルがサーバーに存在しなければ投稿をブロックすることになる。
    また、ファイルの生成時間が新し過ぎる場合もブロックする。stat関数でファイルの作成時間を取得し、現在時間との差がたとえば10秒以下のものはブロックする。
  3. 投稿を受け付ける場合、投稿IDファイルは削除する。拒否する場合も削除すると、慌てて投稿した正規のユーザーが投稿フォームに戻って再度投稿できなくなるので、削除しないことにする。
投稿IDファイルは投稿フォームを表示しないと生成されない。このためフォームを介さず直接投稿用パラメータを送ってくるようなロボットは、該当する投稿IDファイルが存在しないのでその時点でブロックされる。(しかし拒否ログを見てみると、投稿IDを送ってこなかったり、投稿IDの該当ファイルが存在しないというケースは少ない。やはりHTMLでフォームのinput要素を調べてから投稿しているようだ。)
HTMLを解析して隠しタグの投稿IDを取得してから投稿してきても、それが早すぎるとブロックすることになる。
正規の利用者が通常の投稿をする場合、フォームを表示してから、投稿内容を入力して送信ボタンを押すまでは少なくとも数10秒はかかるだろうから、あまり早すぎるもの(たとえば10秒以下)は人間が投稿したものではないと判断することになる。
スパム側の対策として、フォームを表示させてからタイムラグをおいて投稿させることは技術的には難しくはないだろうが、効率よく大量のスパム投稿をしたいロボット側としては、あまりやりたくないと思う。投稿時間ではじかれることがわかったら、タイムラグを作って効率を下げてでも投稿するよりは、もっと効率的に投稿できる他の掲示板を探すのではないだろうか。

ダミーフィールド方式

ネット上を調べるとWord PressのThrows SPAM Awayというプラグインがけっこうスパム防止効果が高いらしい。
以下のような項目をチェックして該当するとブロックするということだ。
  1. 日本語を含んでいない
  2. NGワードが含まれる
  3. リンクが含まれる
  4. ダミーフィールドに入力があった場合(ロボット対策)
  5. IPアドレス一致
  6. 外部提供のスパムリストに一致
1、2、3、5は多くの掲示板プログラムで採用されている対策で特に目新しい方法ではない。
気になったのは4のダミーフィールドに入力があった場合(ロボット対策)という項目。
これは入力してはダメというフィールドを作っておいて、それに入力があったらロボットと判断して拒否するということのようだ。それが効果があるということは、スパム投稿用のロボットというのは、フォームのinput要素すべてに、なんか入れて送るという習性があるのかもしれない。
そういえば入力が任意のフィールドにもすべて何か文字列を入れて投稿しているスパムが多いような気がする。必須フィールドの入力がないために投稿が拒否されることを避けるためだろうか。
これも試す価値がありそうだ。
フォームに実装する場合、「ここには入力しないでください」と書いたテキスト入力フィールドを作るか、あるいはスタイル指定で通常のユーザーは認識されないようなフィールドにしてもいいかも知れない。
ロボットはHTMLコードを読んでいるようなので、そのようなフィールドでもしっかり見つけて入力してくるに違いない。たとえば以下のフォームでは、
 
コメント  
コメントの右はcommentというパラメータ名のtextフィールドだが、これだけでなくこの右にはiamrobotというパラメータの入力フィールドがあるのだが、スタイル指定で非表示になっている。
通常の投稿者はこのiamrobotフィールドには入力しない(というかできない)が、ロボットはここにもなにか書き込んで送信してくる可能性がある。ロボットはHTMLコードを解析していると考えられるからだ。
試してみると、案の定見えないフィールドからも値を送ってきた。効果を期待できそうだ。

実験結果

スパム対策研究用掲示板に投稿ID、ダミーフィールド2つのスパム投稿防止処理を入れてみた。
この掲示板では、フォーム内にパラメータ名が「robot」というダミーのテキストフィールドを追加し、スタイル指定でvisibility:hiddenとして表示されないようにしている。また、フォームを表示するたびにランダムな文字列を生成して投稿IDとし、input hiddenタグに表示するとともに投稿ID名のファイルをサーバーに作成している。

通常の掲示板では、複数のスパム対策処理を行う場合、どれかひとつに引っかかればその時点で処理を中止し拒否するが、この実験用掲示板の場合、どのスパム対策が効果があったのか拒否ログに記録するため、すべてのスパム対策処理を行う。もちろんどれかに引っかかれば最終的には投稿拒否する。これによって各スパム投稿に対してどの対策が効果があるのか分析することができる。拒否ログ閲覧もCGIで行う。
ログを見ると、大量のスパム投稿をブロックしているのがわかる。3種類のタイプがある。
一番多いのが投稿者名、タイトルがひらがなになっていスパムで、これはダミーフィールド、投稿IDの時間チェックどれにも引っかかる。ときどき投稿キーで引っかかることもある。数は多いが、ダミーフィールドから送ってくるのでほぼ確実にブロックできる。

次に本文が英語で投稿者名、タイトルがランダムな英文字になっているスパム。これもダミーフィールド、投稿IDの時間チェックどちらにも引っかかる。投稿キーに引っかかることはないが、ダミーフィールドから送ってくる以上確実にブロックできる。

やっかいなのはタイトルが6ケタの数字になっているスパムで、これはダミーフィールドに引っかからない。投稿キーもスルーするので、なんとか投稿IDの時間チェックでブロックしている状態だ。サーバーが重くなっていたりすると投稿されてしまうおそれがある。

ところで投稿者に入力の手間をかける投稿キーは、残念ながら思ったより効果がないようだ。

eメール入力フィールドを隠す

ほとんどのスパム投稿はeメールアドレスを投稿してくる。
name属性が「robot」のダミーフィールドには引っかからなかったスパム投稿も、eメールアドレス入力欄がダミーになったら送ってくるのではないかと期待して、eメール入力フィールドをスタイル指定の display:none で隠してみた。
すると不思議なことに、スパム投稿がピタッとなくなった。拒否されたログにも記録されなくなった。

これはどう解釈すればいいのだろうか。
eメール入力フィールドを表示しなくなったことによって、ロボットはeメール入力欄がなくなったと思い、eメール入力欄のないフォームには投稿しないというプログラムになっているのか。それともフィールドにdisplay:noneが指定してあればあきらめる設定になっているのか。ちなみにrobotフィールドの方は display:none ではなく visibilty:hidden で隠している。
たまたまスパム投稿が一区切りついたところというだけかもしれないので、とりあえずeメール入力欄を元に戻して様子を見てみる。
eメール入力欄を元に戻したが、明らかに投稿件数が減っている。数分に1回あったひらがなタイトルの投稿がなくなった。eメール入力欄とは関係ないのかもしれない。再度eメール入力欄を非表示にして様子を見ることにする。

スパム投稿が減ると調査はやりにくくなるが、実際に掲示板を設置した場合、ブロックすべき投稿がガンガン来て片っ端から拒否するよりも、最初からそんな投稿がない方がもちろんいい。
テキストフィールドを非表示にするスタイル指定があるフォームは最初から投稿はしないという設定になっているのか?
もしそうなら、CGIにも負担をかけずに済むので、効果的な対策ということになる。
そんなうまい話があるのかと思ったが、その可能性はありそうだ。以下の理由からだ。
投稿IDによる処理では、フォームを表示した時点で投稿IDファイルを作成する。FTPソフトでこの投稿IDファイルを調べると、ブロックしたスパム投稿がない場合もこの投稿IDファイルが次々と作成されていることがわかった。これはフォームだけ表示してみたが、なんか罠が仕掛けられてそうで、うまくいきそうもないので諦めて帰ったという動作を裏付けるものではないか。
投稿IDファイル作成のログも取り、分析してみた。
拒否された投稿以外にもかなりアクセスがあることがわかる。リンク元がなかったり、通常のユーザーのアクセスではあり得ないリンク元になっているケースが多い。通常のユーザーのアクセスがこんなにあるとは思えないので、ほとんどがスパムではないかと思う。しかし、このうち実際に投稿して拒否されるのは一部だ。やはりフォームまで来て何もせずに帰るロボットがいるようだ。
投稿もせずにあきらめるというのもずいぶん弱気なスパムだという気もするが、限られた時間でより大量に投稿する効率を考えると理解できる行動だ。しかしフィールドが隠されているとわかっているなら、そこは値を入れずに投稿することもできると思うのだが。
いずれにしてもこれが有効なら、最初から使わないテキストフィールドを非表示にする記述を追加するだけでスパム防止の効果があるということになるが、もう少し調べないとわからない。

ところでダミーフィールドに引っかからなかった数字タイトルのスパムだが、やはりeメール入力欄を非表示にしてもメールアドレスを送ってくることがわかった。ということはこのメールアドレスを送ってくる投稿も拒否するようにすれば、ブロックできるはずだ。
ダミーのeメールフィールドの入力を拒否するようにしたら、これまで投稿キー、投稿ID、ダミーのrobotフィールドいずれもすり抜けてきたスパムのブロックにやっと成功した。
eメール入力欄でブロック

この掲示板へのこれまでのスパム投稿はすべてメールアドレスを送ってきている。ということはこのメールアドレス送信分をブロックすればほぼすべてのスパム投稿に対応できることになる。
ただし、HTML内のスタイル指定を解析し、input要素を隠す設定になっていたら何らかの対策を行うことになっていれば別だ。スパムはスタイルまでは解析しないというのが、これまでの定説らしいが、この掲示板の拒否ログを見ただけでもdisplay:none;スタイルに反応しているような気配があるので、今後どうなるかわからない。

ダミーフィールドに対するスパムの挙動

しかし同じ非表示のフィールドなのに、送ってくる場合と送ってこない場合があることになるが、何が違うのだろう。ロボットは何を基準に判断しているのだろう。
まずフィールドのname属性が「email」か「robot」かの違いがある。一応name属性も考えているのだろうか。「robot」という名前はさすがに警戒されているかもしれない。すでに非表示フィールドによる拒否を行う掲示板でフィールド名に「robot」がけっこう使われているので、要注意名になっているとか。
非表示にするスタイルが「visibility:hidden」か「display:none;」という違いもある。
スタイルについては、そのほかinputタグに直接スタイルを指定しているか、inputタグを含むタグにしているかの違いもある。
このあたりも調査が必要かもしれないが、現在のデータでは
  1. ダミーフィールドの名前は通常inputタグで使うようなname属性にしておいた方が無難。
  2. 非表示にするの方法は「display:none;」がいい。
  3. 非表示にするスタイルシートはinputタグに直接ではなく、上位のタグに指定する方がいい。
ということがいえる。

eメールを入力させて表示すると、それこそスパムメールに狙われることになるので、当サイトの掲示板はeメール入力を求めないものが多い。入力してもメールアドレスは表示せず、CGIによるメールフォームでメールを送信してもらうことにしている。
なので、eメール入力欄は非表示にしても構わないのだが、やはりメールアドレスを入力して欲しいという場合は、name属性を「email1」などとダミーフィールドとは別にして通常の入力フィールドを表示すれば問題ない。
あるいはダミーフィールド名は「name」や「title」などname属性としてよく使われそうな名前にしてもいいだろう。本物の投稿者名やタイトル入力欄は「name_」や「title_true」などにするとか。
counter:4,290
迷惑投稿対策 2016年08月22日 20:11   編集
トレンドマイクロのセキュリティソフトをインストールしていると、アクセスしたWEBサイトのURLがすべてトレンドマイクロに送られてしまうということがわかりました。
パスワードでアクセス制限されたページも、URLにパスワードが含まれているとそれも送られてしまうため、セキュリティ上大きな問題になります。

これは、悪意のあるプログラムが仕掛けられているWebページへのアクセスをブロックするというWebレピュテーションという機能を有効にすると、こうなるようです。

Webレピュテーションの仕組みは、
  1. WebレピュテーションをいれたユーザーがWebを閲覧すると、そのURLがすべてトレンドマイクロのサーバーに送られる。
  2. そのURLへトレンドマイクロのロボットがアクセスして安全かどうか調べる。
  3. URLが安全かどうかの情報がサーバーのデータベースに送られる。
  4. ユーザーがWebにアクセスしようとすると、データベースに問い合わせて、危険と判断されたらブロックする。
というもののようです。

見慣れないドメイン

迷惑投稿というわけではありませんが、もっとたちが悪いかもしれない問題が出てきました。

ここで公開しているCGIではありませんが、限られたユーザーだけアクセスできるようにベーシック認証で制限をかけているCGIがあります。
外部に出したくないデータを扱っているので、変なところからのアクセスがないか、時々ログをチェックしているのですが、末尾に sjdc とか iad1 がついた見慣れないドメインからのアクセスが目につくようになってきました。

IPアドレスからgethostbyaddrでホストを調べてみると、wtp-g4-maya8.sjdcとかwtp-gs-maya7.sjdc、あるいはwtp-g9-maya6.iad1ということになるのですが、sjdcやiad1などというトップレベルドメインは見たことがありません。
webで調べてみるとどうもトレンドマイクロ社の検索ロボットのようです。
トレンドマイクロ社の製品に入っている機能で、悪意のあるプログラムが仕掛けられているWebページへのアクセスをブロックするというWebレピュテーションというサービスがあるようなのですが、そのデータベース作成のためにロボットが調べているようです。

ログを見ると、トレンドマイクロのソフトを入れたパソコンでページにアクセスすると数分後に同じページにロボットからのアクセスがあります。
どうやらブラウザで見たページのURLがトレンドマイクロに送られ、そのURLをロボットが調べるという流れになっているようです。

トレンドマイクロのサイトで、WEBレピュテーションについて説明したページを見てみると
本機能を有効した場合、お客様がアクセスをしようとしているURLの情報を全て送信します。
また、アクセス先のWebサーバ側の仕様が、お客様が入力した情報や環境情報等をURLのオプション情報として付加しWebサーバへ送信する仕様となっている場合は、URLのオプション情報(ID,パスワードが含まれる場合があります)についても、トレンドマイクロのサーバに送信されます。
という記述が見つかりました。
これって、やってることはスパイウェアといっしょでは。
トレンドマイクロに送られたURLデータがどのように管理されているのかは、わかりませんが、URLが安全か危険かという情報をユーザーに公開している以上、当然URLの情報も公開されてしまうと考えた方が良さそうです。
これまでいっさいアクセスのなかったmsnやgoogleのロボットも来るようになったし。
隠したいURLがオープンになってしまうという点では、スパイウェアよりたちが悪いかもしれません。

Webレピュテーションをインストールする際の使用許諾契約書には当然こうしたことは書いてあるのでしょうが、トレンドマイクロの製品のユーザーが、こうなっていることを認識しているかどうか疑問です。
トレンドマイクロの製品のほとんどにこのWebレピュテーション機能は入っているようなので、かなりのユーザーがID、パスワードを含むURL情報をトレンドマイクロに送っていると考えられます。

とりあえず、件のCGIはトレンドマイクロからのアクセスは拒否するようにしましたが、すでにトレンドマイクロにURL情報が送られているので、ほとんど意味のない抵抗です。

ベーシック認証でもアクセス制限していますが、その情報まで送っているのかどうかは、ウチで取っているログではわかりませんでした。
さすがにそこまでやると問題になるとはおもいますが。

いずれにしても、こうしたスパイウェアもどきのものが出回っている以上、URLでログイン情報を渡すのはやめた方が良さそうです。
ウチで公開しているほかのアクセス制限機能付きCGIでも、制限ページにログイン後のアクションは常にパスワードチェックを行うようにしているので、アクションを送るごとにパスワードをサーバーに送っています。URLで送ることが多いので、これは別の方法を何か考えた方が良さそうです。

アクセス制限の改善案

ということで、対応策を考えてみました。

従来

ログインする際にフォームからID、パスワードを入力させて認証。ログイン後も何かアクションするごとに認証を行うが、その都度ID、パスワードを入力するのは手間なので、ページのリンク先などにID、パスワードを保存し、制限ページ内での操作や移動はパスワードを入力する必要が無いようにしている。
ブラウザのアドレス欄にID、パスワードを含んだURLが表示される。

改善案

ログインする際にID、パスワードを入力するフォームを表示。認証が通ったら、ランダムな文字列から成るログインIDを発行。以後ユーザーが制限ページ内での移動、操作する際は常にこのログインIDを保持する。
ログイン時にユーザーのIPアドレス、ログインIDを含むログインファイルを作成し、ログインページ内での認証は、パスワード認証の替わりに、ユーザーが保持するログインID、ユーザーのIPアドレスを含むログインファイルが存在するかどうかで行う。このログインファイル、ログインIDは一時的なもので、ユーザーがログアウトしたり、有効期限(数分)を過ぎると自動的に削除される。一時的な認証データなので万一ログインIDが外部に漏れたとしても、そのIDでログインすることはできない。万一、正規のユーザーがログイン中、あるいはログインファイルが削除される前にこのログインIDを使ってアクセスしようとしても、アクセス元のIPアドレスもチェックしているので、不正にログインすることはできない。

ウチで公開しているCGIをチェックしてみたところ、結構パスワードをURLで送信するスクリプトがたくさんありました。

長期予定表

パスワードを使用するのは管理者による設定画面にログインしたときだけ。設定画面内の操作は基本的にフォームによるPOST送信だけだが、
編集された設定を設定画面に反映させるため、リダイレクトでパスワードを送信する部分があった。
このリダイレクトを廃止し、別の方法で編集結果を反映させることにした。

詳細予定表

長期予定表と同様に管理者による設定画面ログイン時にリダイレクトでパスワードを送信している部分があったので、廃止。
マルチモードの場合、ユーザーが専用の予定表を作ることができるが、この専用ページにログイン中にパスワードをURLで送信する部分があった。
上記の改善案を取り入れ、ログイン時に認証と同時に一時IDを作成し、IPアドレスと一時IPによる認証方式に変更した。

疑似偏差値計算機

プライベートディレクトリにログインしたときにパスワードを使う。プライベートディレクトリ内の操作はすべてフォームによるPOST送信なので、問題ないと思うが、ログイン直後にメッセージを表示するためにリダイレクトする部分でパスワードを送信している。
これもリダイレクトしない方式に変更する予定。

一斉メール送信CGI

パスワードは使用するが、すべてPOST送信なので、パスワードがURL送信されることはない。

Clip Board改造版

管理者用設定画面で編集後にパスワーを含んだURLにリダイレクトする部分があるので、リダイレクトしないように改修。
counter:3,777