0

ここ数日、ボットが使用する Web フォームを保護する方法についてよく考えていました。使い方は乱用で、約 80 万件のボットのクエリが 8 時間以内に処理されます。

状況の概要を簡単に説明しましょう。不足している情報があればお尋ねください。

ボット:

  1. ボットには異なる IP があります。
  2. ボットは、ユーザー エージェントを実際に存在するものに変更します。
  3. ボットが js をロードして Cookie を持っているかどうかは不明な点です。

問題点：

  1. 外部リソースから送信される可能性があるため、フォームは非表示のトークン フィールドを使用できませんでした。CSRF トークンを認識せず、トークンを生成できないさまざまな Web サイトなどのリソース。CSRFが使えなくなる。
  2. Web サイトはブラウザにキャッシュする必要があり、疑わしい動作などの例外的な状況でのみキャッシュがリセットされる場合があります。
  3. データベースを集中的に使用することはできません (!)。

現在の様子：

  1. 有効期限が何かにハッシュされた Cookie カウンター + 追加の文字は、システムだけがいつ挿入したかを認識します。
  2. ブラウザが Cookie を処理できなかった場合は、データベース ログが使用されました。ユーザーがサーバーに到達しない場合、ブラウザーのキャッシュに問題があります。結果: 検証が実行されておらず、カウンターがインクリメントされていません。
  3. X 回の試行制限を超えたユーザーに reCaptcha が適用されました。

思いついたアイデア：

  1. いくつかのコンテンツを含む iframe を提供し、0 を期限切れにします。iframe は単純な Cookie ロジックを作成します。
  2. Iframe : cookie が設定されていない場合 - 設定し、cookie が設定されている場合は確認します。ユーザーが制限を超えていない場合-カウンター+1を設定し、超えた場合-特定のページに送信すると、キャッシュがリセットされて警告が表示されます。

ここでの難点は、ボットが Cookie をサポートしておらず、コンテンツがキャッシュから提供されている場合はどうなるかということです...ユーザーがサーバーに到達しないため、データベースは何も書き込みません。ただし、ユーザーがキーワードを変更すると、キャッシュがリセットされ、背後のロジックが機能します。

2 番目の問題: ボットが JS をサポートしていない場合 (キーワードを切り替えると、ボットは除外されます)。ただし、コンテンツがキャッシュから提供されている間はリダイレクトできません。

3 つ目の難点: ボットが ReCAPTCHA を解読したら？:)

*質問: *

この状況であなたは何をしていましたか？あなたが考えている手順を説明してください。物事に対するあなたの視点に本当に感謝します。すべてのアイデアは他のアイデアで洗練される可能性があり、優れた保護スキームを考え出すことができます! 君たちありがとう！

4

2 に答える 2

0

したがって、ユーザーのキャッシュと戦うための私の考えは次のとおりです。

iframe 1x1 を使用します。

Expires: 0 で送信されているコンテンツです。ページがキャッシュから読み込まれた場合でも、iframe は毎回提供されます。

私が思いついた別のアイデアは、マウスイベントを記録することです。onmousemove と onkeydown の 2 つは、F5 キーを押してもキャッチします。サーバーに報告し、フラグを設定します。

最終結果 ユーザーがコンテンツを正常に読み込んでいることをシステムの変数に設定するクロークされた CSS を使用することが決定されました。ただし、「ユーザー」がコンテンツを正常にロードする場合、特別な保護は、javascript のイベント追跡 (onmousemove、onkeydown、onclick) を実装し、それをサーバーに送信してフラグを立てることです。リクエストは、イベントが最初に発生したときに一度だけサーバーに送信され、その後追跡されません。

于 2012-12-25T13:38:13.287 に答える
0

事実: いつでもどこからでもフォームの送信を受け入れなければならない場合、基本的にボットに頼ることはできません。ボットは、いつでもどこからでもデータをサーバーに送信します。

CSRF トークンには、データをサーバーに送信する前にサーバーから何かを取得するようにユーザーに要求する役割があります。これにより、サーバーはランダムな送信と「実際の」送信を区別することができます。また、これらのトークンを発行するレートを調整することもできます。これは、JavaScript、ブラウザー ベースのクロス サイト攻撃から保護するためだけのものであり、そのようなトークンをいつでも取得できるボットに対してはあまり効果がありません。

トークンをユーザーに結び付け、認証されたユーザーからのフォーム送信が必要な場合は、送信の制限をより適切に処理できます。ユーザーがデータを送信できるレートを制御でき、誰がどのようにサインアップできるかを制御できます。そのため、データを送信できるユーザーと頻度を把握できます。

これらすべてがなければ、送信の有効性や頻度に関して何も把握できません。ユーザーのマウスの動きの追跡について言及しました...これをどのように実装したいのかわかりませんが、ボットに必要なのは「マウスの動きのように見える」追加データを送信することだけである場合、それも簡単に回避できます。結局のところ、「マウスの動き」はサーバーに送信された単なるデータであり、そのデータがマウスによって生成されたかどうかはわかりません。

つまり、隠しハニーポット フィールド、認証トークン、キャプチャなどのさまざまな手法を使用して、ボットからWeb フォームを保護することができます。ただし、誰でも送信できるオープンな API が必要な場合、これはまったく無意味です。

于 2012-12-25T16:41:06.287 に答える