2009-05-07 9 views
15

私は基本的に間違った方法で私のコードを生成すべきではないWebアプリケーションでいくつかのリクエストを取得しています... 主に、GETパラメータを指定せずに.ashxへのリクエストです。「Mozilla/4.0」というだけのボットはユーザーエージェントですか?

ユーザエージェントは「Mozilla/4.0」です(これ以上のものはありません) IPは日によって異なります。

これはボットですよね?

ありがとうございます!

答えて

9

これは私にとって非常に奇妙なようです。どんな正当なボットでも、あなたが認識できる方法で自分を識別します。どんな悪意のあるボットでも、ユーザエージェントを通常のブラウザのように見せかけることができます。これは真ん中にあります。それは、悪い要求と相まって、私があなたが平凡な古い無能を扱っていると信じるようになります。

どちらの方法でも、黄色い画面エラーを返すのではなく、これらの要求を404にすることをお勧めします。

+0

"予期しないエラー"というだけの、私が作成したデフォルトのエラーページは、YSoDよりも人にやさしく、悪意のある人々からのエラーの詳細も隠しています。 私はそれも500を返すべきだと思うので、ボット*はヒントを得なければなりません。 しかし私はあなたの無能さの理論に完全に同意します。 –

+1

あなたは404のように、ボットに実際のページがあるとは思わないようにします。そうしないと、悪意のあるボットがあとでページの何かを試すことがありますが、今回はラッキーになるかもしれません。そして、検索エンジンは今も巡り続けてから、再びインデックスを作成します。空白のページが404の場合は、ボットはすぐに消えます。 –

5

http://www.user-agents.orgによれば、「Yahoo Mindset:Intent-driven Search」というボットがこれを報告しています。

しかし、それはブラウザがそれを報告することはありません。

1

あなた自身が書いた既存のページへのこれらのリクエストはありますか、または404を受け取っていますか?

後者の場合、脆弱なアプリケーションインスタンスを検出する前に何らかのスキャン攻撃が行われる可能性があります。

+0

いいえ、自分で書いたファイルです(少なくとも、WebResource.axdのように存在します) スクリプトは明らかに他のページのHTMLをチェックすることでそれらを見つけました。 スクリプトがパラメータなしでこれらのファイルを取得しているため、エラーレポートが表示されます –

10

古い質問には申し訳ありませんが、これは中国の偉大なファイアウォールが使用しているボットだと思います。 ウェブコンテンツをクロールし、検閲を行います。

ログを確認し、「GET /cert/bazs.cert」のようなものがあるかどうかを確認してください。

これが見つかると100%確信しています。

+0

ログにbazs.certのリクエストが見つかりませんでしたが、あなたの回答は正しいと思います私が中国の誰かにリンクを送った直後に、このUser-Agentのリクエスト。 – michau

+1

@michauリンクがQQ(IMソフトウェア、中国で人気)に表示されたり、Tencent Traveler(TTブラウザ?)でサイトを閲覧すると、ボットがすぐに表示されます。 Tencentは独自の検索エンジンを持っていますが、User-Agentは 'Mozilla/4.0'だけでなく '... Sosospider ...'のようなものです – Proton

+0

あと数年でこれに追加して申し訳ありません。 "中国の偉大なファイアウォール"の説明は、我々が最も正確であったことがわかりました。 'Mozilla/4.0'のユーザエージェント文字列を使って" China Telecom Shanghai "に戻って、すべてのクライアントアドレスをトレースしました。 –

1

私はいくつかのWebサイト上で追跡asp.net側の要求を実現していたとの記録を見て、私は唯一のユーザーエージェント「のMozilla/4.0」は、この理由のいずれかによって製造することができると言うことができます:

  • 無能
  • 検索ロボット
  • 攻撃ボット

それは私の最初のAndroidが「サファリ3.0」として同定されたことは興味深いですが、最新のAndroidは、「Mozillaの0」として識別されます!したがって、特定のソフトウェア世代に無能を指すのは難しいです。

このようなリクエストごとに404を返すことは、おそらくコンテンツが頻繁に変更される公開Webサイトの場合は、特に検索ロボットにとって最適なアプローチではありません。

一方、宛先が無効なWebResource.axdへのリクエストは、クロスサイトスクリプティング攻撃を指していることに注意してください。このような状況では、SanitizerProviderを使用することをお勧めします。あなたはCross-site_scriptingでこのタイプの攻撃の詳細を読むことができます。

攻撃を識別するもう1つの良い点は、通常は[システムルート]:\ inetpub \ logs \ LogFiles \ W3SVC1にあるIISログファイルです。ここでは、IISログファイルを解析するための私のツールからsnippです:

enter image description here

この例のユーザーエージェントでは問題はなかった、ボットの攻撃は、2つの異なるIPアドレスから「/dbadmin/index.php」要求することにより同定されました。ボットを攻撃しているファイル/ページがいくつかあります。

希望すると、この質問に役立ちます。

関連する問題