3

HTTP トラフィックをリッスンし、人間によって開始された要求を認識しようとするアプリケーションを作成しています。

例: ユーザーがアドレス バーにcnn.comと入力すると、要求が開始されます。次に、他の要求 (XHR など) を破棄しながら、CNN のサーバー応答を見つけたいと考えています 。

ヘッダー情報から、何が何を意味するかをどのように判断できますか?

いくつかの調査を行った後、関連する応答には次のものが含まれていることがわかりました。

  1. コンテンツタイプ: text/html
  2. HTMLには意味のあるタイトルが付いています
  3. ステータス 200 OK
4

3 に答える 3

1

ワイヤ上のビットからは判別できません。HTTP プロトコルには定義済みの形式があり、すべての (壊れていない) ユーザー エージェントはこれに従います。

おそらく、ネットワーク上でユーザーが「cnn.com」を「http://www.cnn.com/」に入力しただけの変換は、プロトコル ペイロードから検出できると考えているでしょう。答えはノーです。できません。

ユーザーにそのような省略表現を許可しているユーザー エージェントを検出するには、ユーザー エージェント アプリケーション (ブラウザーなど) 自体をスヌープする必要があります。

実際、人間以外のエージェントの検出は興味深い問題です (スパムの検出が明らかな動機の 1 つです)。これは、HTTP が NVT プロトコルのファミリーに属しているためです。信じられないかもしれませんが、ネットワーク ターミナル/コンソール プログラム (telnet クライアントなど) で人間が「手動で」プロトコルを実行できるようにするという基本的な考え方があります。 .) つまり、プロトコルは基本的に人間が使用しているかのように設計されています。

于 2013-01-01T21:40:57.783 に答える
0

役立つコードを提供することはできませんが、RefererHTTP ヘッダーを見てください。最初のGETリクエストには があってはなりませんがReferer、ページにリソース (JavaScript、CSS など) のロードを開始すると、Refererはそれらのリソースをリクエストした URL に設定されます。

したがって、ブラウザに「stackoverflow.com」と入力して Enter キーを押すと、ブラウザは次のようGETに no を含むリクエストを送信します。Referer

GET / HTTP/1.1
Host: stackoverflow.com
# ... other Headers

ただし、ブラウザがサポートする静的リソースをページにロードすると、各リクエストには次のRefererようなヘッダーが含まれます。

GET /style.css HTTP/1.1
Host: stackoverflow.com
Referer: http://www.stackoverflow.com
# ... other Headers
于 2013-01-01T21:41:01.690 に答える
0

ボットは実際のユーザーを模倣するように作成されており、ヘッダーは非常に簡単に模倣できるため、ヘッダー情報だけではボットから実際のユーザーを識別するのに十分ではないと思います。

できることの 1 つは、ユーザーがたどったパス (クリックのシーケンス) を追跡することです。これは、ボットによって作成されたものとは異なる可能性が最も高く、投稿された情報を分析します (つまり、ベイジアン フィルター)。

非常に簡単に実装できるチェックは、IP ソースに基づいています。ブラック リストに記載された IP アドレスのデータベースがあります。Project Honeypotを参照してください。Javaでソフトウェアを作成している場合は、IP アドレスを確認する方法の例を次に示します: How to query HTTP:BL for spamming IP addresses .

私がブログで行っていることは次のとおりです (wordpress プラグインを使用):

  1. IP アドレスが HTTP:BL に含まれているかどうかを確認します。それがユーザーにある場合は、ユーザーの IP アドレスをホワイトリストに登録するためのアクションを実行するための HTML ページが表示されます。これは、Wordpress でBad Behaviorプラグインによって行われます。
  2. ユーザーがコンテンツを送信すると、ベイジアン フィルターが送信内容を検証し、コメントがスパムとして識別された場合、送信を完了する前にキャプチャが表示されます。これはakismetと条件付きキャプチャで行われ、コメントも手動承認のためにキューに入れられます。
  3. 一度承認されると、同じユーザーは安全であると見なされ、制限/チェックなしで投稿できます。

上記のルールを適用すると、ブログにスパムがなくなりました。そして、同様のロジックはどの Web サイトにも使用できると思います。

このアプローチの利点は、キャプチャが表示されず、99% の確率で異常が発生しないため、ほとんどのユーザーがセキュリティ メカニズムに気付かないことです。しかし、内部では非常に制限的で効果的なチェックが行われています。

于 2013-01-01T21:39:07.283 に答える