scripting - スクリプターがあなたのウェブサイトを非難するのを止める

Question

回答を受け入れましたが、残念ながら、元の最悪のシナリオにとどまっていると思います。簡単な説明: キャッシング/Web ファームはヒットを追跡することを不可能にし、任意の回避策 (キャッシュされていない Web ビーコンの送信、統合テーブルへの書き込みなど) は、ボットよりもサイトの速度を低下させます。高レベルで役立つ Cisco などの高価なハードウェアがいくつかある可能性がありますが、代替手段として全員に CAPTCHA を適用する場合、コストを正当化するのは困難です。後でより完全な説明を試み、将来の検索者のためにこれを整理します (ただし、コミュニティ wiki であるため、他の人も試してみてください)。

状況

これは woot.com でのバケツ販売についてです。私は Woot の子会社である Woot Workshop の社長であり、デザイン、製品説明の執筆、ポッドキャスト、ブログ投稿、フォーラムのモデレートを行っています。私は CSS/HTML を扱っていますが、他の技術についてはほとんど知りません。私は開発者と緊密に協力し、ここにあるすべての回答 (および私たちが持っていた他の多くのアイデア) について話し合いました。

ユーザビリティは私の仕事の大きな部分を占めており、サイトをエキサイティングで楽しいものにすることが残りのほとんどです。そこから、以下の 3 つの目標が導き出されます。CAPTCHA はユーザビリティを損ない、ボットはくだらないセールから楽しさと興奮を盗みます。

ボットはランダムクラップセールのために、1 秒間に何十回も画面をスクレイピング (および/または RSS をスキャン) してフロントページをバタンと叩いています。彼らがそれを見た瞬間、プログラムの第 2 段階がトリガーされ、ログインして [I want One] をクリックし、フォームに入力して、がらくたを購入します。

評価

lc : このメソッドを使用する stackoverflow やその他のサイトでは、ほとんどの場合、認証された (ログインしている) ユーザーを扱っています。

Woot では、匿名 (ログに記録されていない) ユーザーが私たちのホームページを閲覧できます。言い換えれば、スラミングボットは認証されていない可能性があります (そして、IP アドレス以外では基本的に追跡不可能です)。

そのため、IP のスキャンに戻ります。これは、a) クラウドネットワーキングとスパムボットゾンビのこの時代ではまったく役に立たず、b) 1 つの IP アドレスから来るビジネスの数を考えると、あまりにも多くの罪のない人を捕まえます (言うまでもなく、非静的 IP ISP と、これを追跡しようとするとパフォーマンスが低下する可能性があります)。

ああ、そして、人々が私たちに電話をかけることは、考えられる最悪のシナリオになるでしょう. 彼らにあなたに電話してもらえますか？

BradC : Ned Batchelder の方法はかなりクールに見えますが、サイトのネットワーク用に構築されたボットを打ち負かすようにかなりしっかりと設計されています。私たちの問題は、ボットが私たちのサイトを打ち負かすために特別に構築されていることです. これらの方法のいくつかは、スクリプターがボットを進化させてハニーポットを無視し、フォーム ID の代わりに近くのラベル名をスクリーンスクレイプし、JavaScript 対応のブラウザーコントロールを使用するまで、短期間は機能する可能性があります。

lc 再び: 「もちろん、誇大宣伝があなたのマーケティング計画の一部である場合を除きます.」はい、間違いなくそうです。アイテムが現れたときの驚きと、それを手に入れることができたときの興奮は、おそらく実際に得られるがらくたと同じかそれ以上に重要です. 先着順を排除するものはすべて、がらくたを「勝つ」というスリルを損ないます。

novatrust : そして、私は、新しいボットオーバーロードを歓迎します。実際には、サードパーティのアプリがサイトをスキャンして製品情報を取得できるようにするために、RSS フィードを提供していますが、メインサイトの HTML よりも先にスキャンすることはできません。私の解釈が正しければ、あなたの解決策は、目標 1 を完全に犠牲にして、ボットが大部分を買うという事実を放棄することによって、目標 2 (パフォーマンスの問題) を助けます。あなたの最後の段落の悲観論は私には正確だと感じたので、私はあなたの回答に賛成票を投じました. ここには特効薬はないようです。

残りの応答は一般的に IP 追跡に依存していますが、これも役に立たず (ボットネット/ゾンビ/クラウドネットワーキングで)、有害です (同じ IP の宛先から来る多くの罪のない人を捕まえます)。

他のアプローチ/アイデアはありますか? 私の開発者は「CAPTCHA をやりましょう」と言い続けていますが、私たちのがらくたを欲しがっているすべての実際の人間に邪魔にならない方法があることを願っています.

元の質問

非常に高い認識価値を持つものを安く販売していて、数量が非常に限られているとします。このアイテムをいつ販売するかは誰にもわかりません。そして、100 万人以上の人々が定期的にあなたの商品を見に来ます。

スクリプターやボットは、[a] あなたがそのアイテムをいつ販売しているかをプログラムで把握し、[b] 彼らが最初にそれを購入したことを確認しようとします。これには 2 つの理由があります。

あなたのサイトは人間以外によって非難され、すべての人にとってすべてが遅くなります.
スクリプターは製品を「獲得」することになり、常連はだまされたと感じます。

一見明白な解決策は、ユーザーが注文する前にジャンプするためのフープを作成することですが、これには少なくとも 3 つの問題があります。

CAPTCHA を解読したり、猫を見つけたり、数学の問題を解いたりする必要があるため、ユーザーエクスペリエンスは人間にとって最悪です。
認識された利益が十分に高く、群衆が十分に大きい場合、一部のグループは微調整を回避して軍拡競争につながる. (これは、微調整が単純であるほど特に当てはまります。非表示の「コメント」フォーム、フォーム要素の再配置、それらの誤ったラベル付け、非表示の「落とし穴」テキストはすべて一度に機能し、その後、この特定のフォームをターゲットにして戦うために変更する必要があります。 .)
スクリプターがあなたの微調整を「解決」できなくても、彼らがあなたのフロントページをバタンと閉め、スクリプターが注文を手動で記入するように警報を鳴らすのを防ぐことはできません. [a] を解決することでアドバンテージを得たとしても、注文ページに到達する最初の人間になるため、[b] を勝ち取る可能性は高くなります。さらに、1. は引き続き発生し、サーバーエラーが発生し、すべてのユーザーのパフォーマンスが低下します。

もう 1 つの解決策は、頻繁にアクセスする IP を監視するか、それらをファイアウォールからブロックするか、または別の方法で IP が注文されないようにすることです。これにより 2. が解決され、[b] が防止される可能性がありますが、IP のスキャンによるパフォーマンスへの影響は大きく、スクリプト作成者が独自に引き起こした問題よりも 1. のような問題を引き起こす可能性があります。さらに、クラウドネットワーキングとスパムボットゾンビの可能性があるため、IP チェックはほとんど役に立ちません。

3 番目のアイデアは、注文フォームをしばらくの間 (たとえば 0.5 秒) 強制的に読み込ませることで、迅速な注文の進行が遅くなる可能性があります。実際のユーザー。

目標

スクリプトを使用しない人間にアイテムを販売します。
ボットによって速度が低下しない速度でサイトを実行し続けます。
「通常の」ユーザーが人間であることを証明するために完了するタスクを実行するのに煩わされないでください。

score 241 · Accepted Answer

SO のようなものを CAPTCHA で実装するのはどうですか?

サイトを通常どおり使用している場合、おそらく表示されることはありません。同じページを頻繁にリロードしたり、連続してコメントを投稿するのが早すぎたり、アラームをトリガーする何かがある場合は、それらが人間であることを証明してください. あなたの場合、これはおそらく同じページの絶え間ないリロード、ページ上のすべてのリンクをすばやくたどる、または注文フォームへの入力が速すぎて人間には不可能です。

チェックに x 回連続して失敗した場合 (たとえば、2 回または 3 回)、その IP にタイムアウトなどの措置を講じます。次に、タイムアウトの終わりに、それらを再びチェックにダンプします。

サイトにアクセスするユーザーの登録を解除したため、続行するのは IP のみです。必要に応じて、各ブラウザーにセッションを発行し、その方法で追跡できます。そしてもちろん、あまりにも多くのセッションが連続して (再) 作成されている場合 (ボットが Cookie を削除し続ける場合) には、ヒューマンチェックをスローします。

あまりにも多くの罪のない人を捕まえる限り、ヒューマンチェックページに免責事項を表示できます。これ。" (文言は適宜調整してください。)

さらに、X 人が 1 つの IP から同時に同じページをロードしている確率は? 値が高い場合は、ボットアラームに別のトリガーメカニズムが必要な可能性があります。

編集: もう 1 つのオプションは、失敗が多すぎて、製品の需要に自信がある場合、それらをブロックして、ブロックを解除するように個人的に電話をかけることです。

人々に電話をかけてもらうというのは馬鹿げた手段のように思えますが、コンピュータの背後のどこかに人間がいることを確認します。重要なのは、ボットでない限り、ほとんど発生しないはずの状態に対してのみブロックを配置することです (たとえば、チェックに何度も失敗するなど)。次に、人間とのやり取りを強制します-電話に出ます。

彼らに私に電話してもらうというコメントに応えて、ここには明らかにそのトレードオフがあります。ユーザーがセール時に数回の電話を受けられるように、ユーザーが人間であることを確認するのに十分な心配がありますか? 製品が人間のユーザーに届くことをそれほど気にかけているとしたら、この決定を下す必要があり、おそらくその過程で (わずかな) 時間を犠牲にすることになるでしょう。

ボットにサイトを攻撃させたり、サイトを非難させたりしないと決意しているように見えるので、電話が良い選択肢になると思います。私はあなたの製品から利益を得ていないので、これらの電話を受けることに興味はありません. しかし、あなたがその利益の一部を分けてくれたら、私は興味を持つようになるかもしれません. これはあなたの製品であるため、どの程度気にかけ、それに応じて実装するかを決定する必要があります。

ブロックを解放する他の方法は、それほど効果的ではありません: タイムアウト (しかし、彼らはあなたのサイトを再びバタンと閉めるでしょう。それらはSOLであり、チェックに失敗した場合は罰せられます）、電子メール（ボットによって簡単に行われます）、ファックス（同じ）、または普通郵便（時間がかかりすぎます）。

もちろん、代わりに、タイムアウトになるたびに IP ごとにタイムアウト期間を増やすこともできます。うっかりして真の人間を罰していないことを確認してください.

score 203 · Accepted Answer

12mm 蝶ナット: $20. 脚本家がゲームをしていると判断する前に、どれだけのボットがスナップするかを確認してください。

利益を利用して、サーバーをさらに購入し、帯域幅の料金を支払います。

score 164 · Accepted Answer

私の解決策は、「ボットとスクリプト」を約 10 分間遅らせて、スクリーンスクレイピングを無駄にすることです。

これが私がそれを行う方法です：

リピートヒッターを記録して特定します。

ヒットごとにすべての IP アドレスをログに記録する必要はありません。20 ヒットごとに 1 つだけを追跡します。再犯者は、ランダム化された時折の追跡に引き続き表示されます.

約 10 分前のページのキャッシュを保持します。
リピーター/ボットがあなたのサイトにアクセスしたら、10 分間古いキャッシュページを提供します。

彼らは、古いサイトを取得していることをすぐには知りません。彼らはそれとすべてをこすり落とすことができますが、「現実の人々」は10分の有利なスタートを切るため、もはやレースに勝つことはできません.

利点：

ユーザーの手間や問題はありません (CAPTCHA など)。
サーバー側で完全に実装されています。(Javascript/Flash に依存しない)
キャッシュされた古いページを提供すると、ライブページよりもパフォーマンスが低下するはずです。この方法で実際にサーバーの負荷を減らすことができます!

欠点

一部の IP アドレスの追跡が必要
古いページのキャッシュを保持および維持する必要があります。

どう思いますか？

score 54 · Accepted Answer

ned Batchelder によるこの記事をご覧ください。彼の記事はスパムボットの阻止に関するものですが、同じテクニックをあなたのサイトにも簡単に適用できます。

ボットを阻止するには、人々に自分自身を名乗るようにさせるのではなく、投稿を成功させにくくしたり、うっかりボットとして名乗ったりすることで、ボットを阻止することができます。これにより、ユーザーの負担が軽減され、コメントフォームに目に見えるスパム対策が不要になります。

このテクニックは、私がこのサイトでスパムボットを防ぐ方法です。できます。ここで説明する方法は、コンテンツをまったく見ていません。

その他のアイデア:

製品が発売されたときに人々が購読できる公式の自動通知メカニズム (RSS フィード? Twitter?) を作成します。これにより、人々がスクリプトを作成する必要性が減ります。
新しいアイテムが発売される直前に、難読化の手法を変更してください。そのため、スクリプト作成者が軍拡競争をエスカレートできたとしても、常に 1 日遅れています。

編集:完全に明確にするために、上記のネッドの記事では、ボットがフォームを介して注文を送信するのを防ぐことにより、アイテムの自動購入を防ぐ方法について説明しています。彼の技術は、ボットがホームページのスクリーンスクレイピングを行って、Bandoleer of Carrots がいつ売りに出されるかを判断するのを防ぐのには役に立ちません。それを防ぐことが本当に可能かどうかはわかりません。

Ned の戦略の有効性に関するあなたのコメントについて: はい、彼はハニーポットについて議論していますが、それが彼の最強の戦略だとは思いません。SPINNERについての彼の議論は、私が彼の記事に言及した最初の理由です。申し訳ありませんが、元の投稿でそれを明確にしませんでした:

スピナーは、いくつかの目的で使用される隠しフィールドです。改ざんやリプレイを防止するために多数の値をハッシュし、フィールド名を隠すために使用されます。スピナーは、次の MD5 ハッシュです。

タイムスタンプ、

クライアントの IP アドレス、

コメントされているブログエントリのエントリ ID、および

秘密。

WOOT.comでそれを実装する方法は次のとおりです。

新しいアイテムが発売されるたびに、ハッシュの一部として使用される「秘密」の値を変更します。これは、誰かがアイテムを自動購入するように BOT を設計しようとしている場合、次のアイテムが販売されるまでしか機能しないことを意味します!!

誰かが自分のボットをすばやく再構築できたとしても、他のすべての実際のユーザーは既に BOC を購入しており、問題は解決されています!

彼が議論しているもう 1 つの戦略は、ハニーポットの手法を時々変更することです (これも、新しいアイテムが発売されたときに変更します) 。

CSS クラス (もちろんランダム化) を使用して、フィールドまたはそれを含む要素を display:none に設定します。
ページの背景と同じ (または非常に似た) フィールドに色を付けます。
ページの可視領域の外にフィールドを移動するには、配置を使用します。
含まれるハニーポットフィールドを表示するには要素を小さすぎます。
フィールドは表示されたままにしますが、配置を使用してそれらを覆い隠す要素で覆います。
Javascript を使用してこれらの変更を有効にします。ボットには完全な Javascript エンジンが必要です。
ハニーポットは他のフィールドと同じように表示されたままにしますが、そこには何も入力しないように人々に伝えてください。

私の全体的な考えは、新しいアイテムが発売されるたびにフォームのデザインを変更することだと思います. または、少なくとも、新しい BOC が発売されたときに変更してください。

月に数回、何ですか？

この回答を受け入れていただければ、次の回答がいつになるか教えていただけますか? :)

score 44 · Accepted Answer

Q：スクリプト作成者が1秒間に何百回もサイトを非難するのをどのように阻止しますか？
A：違います。外部エージェントによるこの動作を防ぐ方法はありません。

膨大な数のテクノロジーを使用して、着信リクエストを分析し、ヒューリスティックに人間であるかどうかを判断しようとすることができますが、失敗します。最終的には、すぐにではないにしても。

実行可能な唯一の長期的な解決策は、サイトがボットフレンドリーにならないように、またはスクリプト作成者にとって魅力的でないようにゲームを変更することです。

どうやってそれをしますか？まあ、それは別の質問です！;-)

..。

OK、いくつかのオプションが上で与えられました（そして拒否されました）。私はあなたのサイトを一度しか見たことがないのでよく知りませんが、人々は画像のテキストを読むことができ、ボットはこれを簡単に行うことができないため、アナウンスを画像に変更します。CAPTCHAではなく、単なる画像-

ページが要求されたときに画像を生成します（もちろんキャッシュされます）
画像のソース名を同じにして、ゲームに影響を与えないようにします
ほとんどの場合、画像には通常のテキストが含まれ、インラインHTMLページの一部として表示されるように配置されます。
ゲームが「オン」の場合、画像はアナウンステキストに変わります
アナウンステキストには、賞品を獲得するために手動で入力する必要のあるURLやコードが示されています。必要に応じてコードをキャプチャしますが、おそらく必要ありません。
セキュリティを強化するために、コードはリクエスト/ IP /エージェント用に特別に生成されたワンタイムトークンにすることができるため、リクエストを繰り返すと異なるコードが生成されます。または、オンデマンド生成に負担がかかりすぎる場合は、ランダムコードの束（ワンタイムパッド）を事前に生成できます。

これに応答する実際の人々のタイムトライアルを実行し、この時間の半分よりも速く応答を無視します（「おっと、エラーが発生しました、申し訳ありません！もう一度やり直してください」）。このイベントは、少なくとも1つのボットがコード/ゲームを理解したというアラートを開発者にトリガーする必要があるため、コード/ゲームを変更するときが来ました。

とにかく定期的にゲームを変更し続けます。ボットがトリガーしなくても、スクリプト作成者の時間を無駄にするだけです。最終的に、スクリプターはゲームに飽きて他の場所に行く必要があります...私たちは願っています;-)

最後の提案：メインページのリクエストが届いたら、それをキューに入れて、別のプロセスで順番にリクエストに応答します（これを行うには、Webサーバーをハック/拡張する必要があるかもしれませんが、おそらく価値がある）。最初のリクエストがキューにある間に同じIP/エージェントからの別のリクエストが入った場合は、それを無視してください。これにより、ボットからの負荷が自動的に軽減されます。

編集：画像の使用以外の別のオプションは、JavaScriptを使用して購入/購入なしのテキストを入力することです。ボットがJavaScriptを解釈することはめったにないため、ボットには表示されません。

score 30 · Accepted Answer

これがどれほど実現可能かはわかりません：...攻撃を続けてください。

ボットがスキャンしているデータを把握します。あなたががらくたを売っていないときに、彼らが探しているデータを彼らに与えてください。これは、人間のユーザーを悩ませたり混乱させたりしない方法で行ってください。ボットがフェーズ 2 をトリガーすると、ボットはログインしてフォームに記入し、BOC の代わりに 100 ドルのルンバを購入します。もちろん、これはボットが特に堅牢ではないことを前提としています。

もう 1 つのアイデアは、バッグオクラップセール期間中にランダムな値下げを実装することです。20ドルの価値しかないことを明確に述べているのに、150ドルでランダムなバッグを買う人はいますか? 熱狂的なボット以外の誰も。しかし、9 分後には 35 ドルになり、17 分後には 9 ドルになります。または何でも。

確かに、ゾンビ王は反応できるでしょう。ポイントは、彼らの過ちが彼らにとって非常に高くつくようにすることです（そして、彼らと戦うためにあなたにお金を払わせるようにすることです）.

これはすべて、あなたが一部のボットロードを怒らせたいと考えていることを前提としていますが、これは 100% 推奨できるわけではありません。

score 22 · Accepted Answer

したがって、問題は実際にあるように思われます。ボットは、低い知覚価格で高い知覚価値を持っているため、「バッグ」を望んでいます。あなたは時々このアイテムを提供し、ボットはそれが利用可能かどうかを確認するのを待って潜んでいて、それから彼らはアイテムを購入します。

ボットの所有者は利益を上げている（または潜在的に利益を上げている）ように見えるので、コツは、がらくたを購入するように勧めることによって、これを彼らにとって不採算にすることです。

まず、常に「bag'ocrap」を提供します。

第二に、がらくたが通常がらくたであることを確認してください。

第三に、がらくたを頻繁に回転させます。

シンプルですね

「なぜ私たちのがらくたは時々がらくたなのか」という恒久的なものが必要になります。何が起こっているのかを人間に説明するためのオファーの横にあるリンク。

ボットががらくたがあることを確認し、がらくたが自動的に購入されると、受信者は壊れたつまようじに10ドルを支払ったことにひどく腹を立てます。そして、空のゴミ袋。そして、靴の底からの汚れ。

彼らが比較的短期間でこのがらくたを十分に購入した場合（そしてあなたがこれをしている理由を説明する大きな免責事項がいたるところにある場合）、彼らはあなたの「バッグ'oがらくた"。あなたががらくたを十分に頻繁に回転させるならば、彼らの側での人間の介入（がらくたががらくたでないことを確認すること）でさえ失敗する可能性があります。ちなみに、ボットはローテーションの期間が短すぎることに気づき、何も購入しないかもしれませんが、それは人間が非がらくたを購入することを意味します。

一体、あなたの常連客はあなたがこれを巨大なマーケティングの勝利に変えることができるほど面白がっているかもしれません。「がらくた」コイがどれだけ売られているかを投稿し始めます。人々は、ボットがどれほど激しく噛まれたかを見るためだけに戻ってきます。

更新： 私はあなたが不平を言う人々と前もっていくつかの電話を受けるかもしれないと期待しています。それを完全に止めることはできないと思います。ただし、これによりボットが強制終了された場合は、いつでも停止して後で再起動できます。

score 13 · Accepted Answer

Woot がこの問題に対処するために使用する方法は、文字通りゲームを変えることです。非常に魅力的な商品を販売する場合、注文するためにユーザーにビデオゲームをプレイさせます。

これはボットとの戦いに成功するだけでなく (彼らは簡単にゲームにマイナーな変更を加えて自動プレイヤーを回避したり、販売ごとに新しいゲームを提供したりすることさえできます)、スローダウンしながら目的のアイテムを「獲得」したという印象をユーザーに与えます。注文プロセス。

それはまだすぐに売り切れますが、解決策は良いと思います。問題を再評価し、パラメーターを変更することで、厳密に技術的な解決策が存在しなかった戦略が成功しました.

ビジネスモデル全体が「先着順」に基づいています。ラジオ局が行ったことを行うことはできません (最初の発信者を勝者にするのではなく、5 番目または 20 番目または 13 番目の発信者を勝者にします)。

いいえ、実際のユーザーの注文エクスペリエンスを変更せずにこれを行う方法はありません。

これらすべての戦術を実装するとしましょう。これが重要だと判断した場合は、単純に 100 人に協力してもらい、100 台の個別のコンピューターで動作するソフトウェアを構築し、サイトに 1 秒間に 20 回アクセスします (各ユーザーのアクセス間隔は 5 秒/クッキー/アカウント/IP アドレス)。

次の 2 つの段階があります。

トップページを見ている
注文

キャプチャをブロックすることはできません #1 - それは実際の顧客を失うことになります (「えっ? 最新の情報を見たいと思うたびにキャプチャを解決しなければならない?!?」)。

私の小さなグループは一緒に時間を計って、1 秒あたり約 20 のチェックを取得し、変更を最初に見た人は誰でも (自動的に) 他のすべての人に警告し、もう一度フロントページをロードし、注文リンクをたどり、トランザクションを実行します (これは、captcha を実装して wootoff/boc ごとに変更しない限り、自動的に発生することもあります)。

＃2の前にキャプチャを配置できます.これは、ボットがフロントページを見たとしても、実際のユーザーが製品を入手していることを確認する唯一の方法かもしれません.

しかし、キャプチャがあったとしても、私の 100 人の小さなバンドには、依然として重要な先行者優位性があります。アクセスのタイミングを計り始めると、ジッターが追加されるだけです。どのコンピューターを更新するかをランダムに選択できるため、アクセスの順序が常に変化しますが、それでも十分に人間のように見えます。

まず、単純なボットを取り除きます

リクエストを監視するアダプティブファイアウォールが必要です。誰かが明らかなばかげたことをしている場合、同じ IP で 1 秒に 2 回以上リフレッシュしてから、それらを遅くする戦術を採用します (パケットをドロップする、拒否されたものを送り返す、または 500 エラーなど)。）。

これにより、トラフィックが大幅に減少し、ボットユーザーが採用する戦術が変わるはずです。

次に、サーバーを非常に高速にします。

あなたは本当にこれを聞きたくない...しかし...

あなたが必要としているのは、ボトムアップからの完全なカスタムソリューションだと思います。

TCP/IP スタックをいじる必要はありませんが、ユーザー接続を相互に関連付け、さまざまな攻撃に適切に対応するために構築された、非常に非常に高速なカスタムサーバーを開発する必要がある場合があります。

Apache、lighthttpd などはすべて柔軟性に優れていますが、単一目的の Web サイトを運営しているため、現在のサーバーが実行できる以上のことを実行できる必要があります (トラフィックの処理とボットとの適切な闘いの両方において)。）。

カスタムサーバーで主に静的な Web ページ (30 秒ごとに更新) を提供することで、10 倍の数の要求とトラフィックを処理できるようになるだけではありません (サーバーは要求の取得と読み取り以外に何もしていないため)。メモリから TCP/IP バッファへのページ) だけでなく、ボットの速度を低下させるのに役立つ可能性があるメトリックへのアクセスも提供します。たとえば、IP アドレスを関連付けることで、1 つの IP につき 1 秒あたり複数の接続を簡単にブロックできます。人間はそれより速く動くことはできず、NAT された同じ IP アドレスを使用している人々でさえ、ブロックされることはめったにありません。スローブロックを実行する必要があります。セッションを正式に終了する前に、接続を 1 秒間そのままにしておきます。これは、特に悪質な犯罪者に長期的なブロックを与えるために、ファイアウォールにフィードすることができます.

しかし現実には、何をしようとも、ボットが 1 つの目的のために人間によってカスタム構築されている場合、人間とボットを区別する方法はありません。ボットは人間の代理にすぎません。

結論

結局のところ、トップページを見ている人間とコンピューターを見分けることはできません。注文段階でボットを止めることはできますが、それでもボットユーザーには先行者の優位性があり、管理する負荷は依然として膨大です。

シンプルなボットにブロックを追加できます。これにより、バーが上がり、気にする人が少なくなります. それで十分かもしれません。

しかし、基本モデルを変更しないと、運が悪くなります。あなたができる最善のことは、単純なケースに対処し、サーバーを一般ユーザーが気付かないほど高速にし、非常に多くのアイテムを販売して、数百万のボットを持っていても、必要な数の一般ユーザーがそれらを入手できるようにすることです。 .

ハニーポットを設定し、ユーザーアカウントをボットユーザーとしてマークすることを検討するかもしれませんが、それにはコミュニティからの大きな否定的な反発が生じるでしょう。

「まあ、これはどうしよう…」と考えるたびに、適切なボット戦略でいつでも対抗できます。

フロントページを注文ページにアクセスするためのキャプチャ (「この商品の注文ボタンは、このページのどこかにあるピンク色の輝きのある青です」) にしても、ボットはページ上のすべてのリンクを開き、表示されたリンクを使用します。注文ページに戻ります。これだけでは勝てません。

サーバーを高速化し、注文ページに reCaptcha (私が見つけた唯一のもので、簡単にだまされることはありませんが、アプリケーションにとっては遅すぎる可能性があります) を配置し、モデルを少し変更する方法を考えてください。通常のユーザーは、ボットユーザーと同じくらいチャンスがあります。

-アダム

score 11 · Accepted Answer

API を使用して価格情報を公開すると言います。これは直感的でない解決策ですが、状況を制御できるようにするために機能します。API にいくつかの制限を追加して、Web サイトよりも機能をわずかに低下させます。

注文についても同じことができます。目的の効果が得られるまで、API の機能/パフォーマンスを少し変更して試すことができます。

IP チェックを無効にするプロキシとボットネットがあります。非常に優れたキャプチャ読み取りスクリプトがあります。インドには、わずかな費用でキャプチャを打ち負かす労働者のチームさえあります。あなたが思いつく解決策は、合理的に打ち負かされる可能性があります。Ned Batchelder のソリューションでさえ、WebBrowser コントロールやその他のシミュレートされたブラウザーをボットネットやプロキシリストと組み合わせて使用することで、一歩踏み出すことができます。

score 11 · Accepted Answer

免責事項：この回答は、プログラミングとはまったく関係ありません。ただし、そもそもスクリプトの理由を攻撃しようとします。

もう 1 つのアイデアは、本当に数量が限られているのであれば、先着順の方法から変えてみませんか。もちろん、誇大宣伝があなたのマーケティング計画の一部でない限り.

他にも多くのオプションがあり、他の人がいくつかの異なるオプションを考えることができると確信しています:

注文待ち行列 (事前注文システム) - 一部のスクリプトはまだ待ち行列の先頭にいる場合がありますが、手動で情報を入力する方がおそらく高速です。
ラッフルシステム (注文しようとする人は誰でもシステムに参加できます) - このようにして、台本を持っている人は持っていない人と同じチャンスがあります。
急ぐ優先キュー - 本当に価値が高いと認識されている場合、人々は喜んでより多くの金額を支払う可能性があります。注文キューを実装しますが、人々がより多く支払うことでキューの上位に配置できるようにします。
オークション (これについては David Schmitt の功績によるもので、コメントは私自身のものです) - スクリプトを使用して土壇場で狙撃することはできますが、価格構造が変わるだけでなく、他のユーザーと競うことを期待しています。 . また、特定の期間内の入札数を制限したり、認証コードのために事前に電話をかけたりすることもできます。

score 8 · Accepted Answer

現在、これを行うために F5 の最新世代の BigIP ロードバランサーを使用しています。BigIP には高度なトラフィック管理機能があり、単一の IP の背後にある一連のソースの中からでも、頻度と使用パターンに基づいてスクレイパーとボットを識別できます。次に、これらを調整したり、代替コンテンツを提供したり、単にヘッダーや Cookie でタグ付けしたりして、アプリケーションコードでそれらを識別できるようにします。

score 7 · Accepted Answer

まず、ここで何をする必要があるかを要約します。元の質問を言い換えているだけだと思いますが、これを 100% 正しく理解することが重要です。なぜなら、4 問中 2 問または 3 問正解する素晴らしい提案がたくさんあるからです。すべての要件をカバーする多面的なアプローチ。

要件 1: 「ボットスラミング」を取り除く:

フロントページの連射がサイトのパフォーマンスを低下させており、これが問題の核心です。「スラミング」は、単一 IP ボットと、おそらくボットネットの両方から発生します。私たちは両方を取り除きたいと思っています。

要件 2: ユーザーエクスペリエンスを台無しにしないでください。

人間のオペレーターに電話をかけたり、一連の CAPTCHA を解決したりするなどの厄介な検証手順を実装することで、ボットの状況をかなり効果的に修正できますが、それは、罪のない飛行機の乗客全員に、わずかなチャンスのためだけにクレイジーなセキュリティフープを飛び越えるように強制するようなものです。非常に愚かなテロリストを捕まえることです。待ってください - 私たちは実際にそうしています。しかし、woot.com でそれができないかどうか見てみましょう。

要件 3: 「軍拡競争」を回避する:

おっしゃる通り、スパムボットの軍拡競争に巻き込まれたくはありません。したがって、非表示またはごちゃごちゃしたフォームフィールド、数学の問題などの単純な微調整は使用できません。

要件 4: 「アラーム」ボットの阻止:

これは、要件の中で最も困難な場合があります。効果的な人間による検証の課題を作成できたとしても、ボットは依然としてフロントページをポーリングし、新しいオファーがあるときにスクリプト担当者に警告する可能性があります。それらのボットも実行不可能にしたいと考えています。これは最初の要件のより強力なバージョンです。なぜなら、ボットはパフォーマンスに悪影響を与える速射リクエストを発行できないだけでなく、勝つために間に合うようにスクリプト作成者に「アラーム」を送信するのに十分な数の繰り返しリクエストを発行することさえできないからです。オファー。

では、4 つの要件をすべて満たすことができるかどうか見てみましょう。まず、前述したように、1 つの手段でうまくいくわけではありません。それを達成するには、いくつかのトリックを組み合わせる必要があり、2 つの煩わしさを飲み込む必要があります。

フープを飛び越えるには少数のユーザーが必要です
一部のユーザーは特別オファーを取得できません

これらが煩わしいことは承知していますが、「小さい」数を十分に小さくすることができれば、プラスがマイナスを上回ることに同意してくれることを願っています.

最初の対策: ユーザーベースのスロットリング:

これは非常に簡単です。あなたはすでにやっていると思います。ユーザーがログインしていて、1 秒間に 600 回 (または何か) 更新し続ける場合、応答を停止し、冷やすように伝えます。実際、おそらくそれよりもはるかに早く彼のリクエストを抑制しますが、その考えは理解できます。このようにして、ログインしたボットは、サイトのポーリングを開始するとすぐに禁止/抑制されます. これは簡単な部分です。認証されていないボットは私たちの本当の問題です。

2 番目の対策: ほぼすべての人が提案する、何らかの形式の IP スロットリング:

いずれにせよ、「ボットスラミング」を阻止するために、IP ベースの調整を行う必要があります。認証されていない (ログインしていない) 訪問者に特別オファーを提供できるようにすることが重要と思われるため、最初は IP しか使用できず、完全ではありませんが、単一IP ボットに対して機能します。ボットネットは別の獣ですが、それらに戻ります. 今のところ、速攻の単一 IP ボットを打ち負かすために、いくつかの簡単な調整を行います。

他のすべての処理の前に IP チェックを実行し、スロットリングロジックにプロキシサーバーを使用し、memcached ルックアップに最適化されたツリー構造に IP を保存する場合、パフォーマンスへの影響は無視できます。

3 番目の対策: キャッシュされた応答でスロットルをクローキングします。

速攻の単一 IP ボットが抑制されているため、低速の単一 IP ボットに対処する必要があります。スロットリングが防止するよりもわずかにリクエストを離すことにより、「レーダーの下を飛ぶ」ように特別に調整されたボット。

遅い単一 IP ボットを即座に役に立たなくするには、abelenky によって提案された戦略を使用するだけです: 過去 24 時間 (またはその程度) に発見されたすべての IP に 10 分間キャッシュされたページを提供します。そうすれば、すべての IP は 1 日、1 時間、1 週間 (選択した期間によって異なります) に 1 回の「チャンス」を獲得し、「リロード」を押している実際のユーザーに、勝てないことを除いて目に見える煩わしさはありません。オファー。

この対策の優れた点は、ボットネットから発信されていない限り、「アラームボット」も阻止できることです。

(実際のユーザーが何度も更新を許可されている場合は、おそらくそれを好むと思いますが、CAPTCHA などを使用せずに、更新をスパムする人間と要求をスパムするボットを区別する方法はありません)

4 番目の対策: reCAPTCHA:

CAPTCHA はユーザーエクスペリエンスを損なうため、避けるべきであることは間違いありません。ただし、_1_状況では、彼らはあなたの親友になる可能性があります。ボットを阻止するために非常に制限的なシステムを設計した場合、その制限性のために、多くの誤検出も検出されます。その場合、最後の手段としてCAPTCHAを使用すると、実際のユーザーがスロットリングをすり抜けることができます (したがって、迷惑な DoS 状況を回避できます)。

もちろん、スイートスポットは、すべてのボットがネットに引っかかるときですが、CAPTCHA に煩わされる実際のユーザーはほとんどいません。

10 分間前のキャッシュページを提供するときに、代替のオプションの CAPTCHA 検証済みの「フロントページリフレッシャー」も提供する場合、本当に更新を続けたい人は、古いキャッシュページを取得しなくても更新できます。、ただし、更新ごとにCAPTCHAを解決する必要があるという犠牲を払って. これは煩わしいことですが、チャンスを増やすためにシステムをゲームしていることを知っているため、より寛容になる傾向がある頑固なユーザーのためのオプションであり、チャンスの向上は無料ではありません.

5番目の措置：おとりのがらくた：

クリストファー・マハンのアイデアは私がかなり気に入っていましたが、私は別のひねりを加えることにしました。新しいオファーを準備するたびに、20 ドルの 12 mm 蝶ナットのように、他の 2 つの「オファー」も準備します。オファーが最初のページに表示されたら、3 つの「オファー」すべてを同じ画像に入れ、各オファーに対応する番号を付けます。ユーザー/ボットが実際に商品を注文するときは、希望するオファーを (ラジオボタンで) 選択する必要があります。ほとんどのボットは単に推測するだけなので、3 分の 2 のケースでは、ボットは価値のないものを購入します。ジャンク。

当然のことながら、これは「アラームボット」に対処するものではなく、誰かが正しいアイテムを選択できるボットを作成できる可能性が (わずかに) あります。ただし、誤ってジャンクを購入するリスクがあるため、スクリプト作成者は完全に自動化されたボットから完全に離れることになります。

第 6 の対策: ボットネットスロットリング:

【削除】

わかりました............私は今、夜のほとんどをこれについて考え、さまざまなアプローチを試して過ごしました....グローバルな遅延.... Cookieベースのトークン..キューに入れられたサービング... 「見知らぬ人のスロットリング」....そして、それはうまくいきません。そうではありません。あなたがまだ回答を受け入れていない主な理由は、分散型/ゾンビネット/ボットネット攻撃を阻止する方法を誰も提案していなかったことに気付きました....だから、私は本当にそれを解読したかったのです。別のスレッドで認証のボットネットの問題を解決したと思うので、あなたの問題にも大きな期待を寄せていました. しかし、私のアプローチはこれには当てはまりません。通過する IP だけがあり、十分に大きなボットネットは、IP アドレスに基づく分析では明らかになりません。

これで、 6 番目の小節がゼロになりました。何もない。ジップ。ボットネットが小さく、かつ/または通常の IP スロットルに引っかかるほど高速でない限り、CAPTHA などの人間による明示的な検証を必要としないボットネットに対する効果的な対策はないと思います。申し訳ありませんが、上記の5つの対策を組み合わせるのが最善の策だと思います。そして、おそらく abelenky の 10 分間のキャッシュトリックだけでうまくいくでしょう。

score 6 · Accepted Answer

一種の「CAPTCHA ゲーム」のように、人間の操作が必要な遅延を導入するのはどうですか。たとえば、30 秒間に市松模様のボールを破裂させ、ソリッドボールの破裂を回避する (色盲の問題を回避する) 必要がある、小さな Flash ゲームである可能性があります。ゲームには乱数シードが与えられ、ゲームがサーバーに送り返すのは、使用されたシードとともに、クリックされたポイントの座標とタイムスタンプです。

サーバー上で、そのシードを使用してゲームの仕組みをシミュレートし、クリックが実際にボールを破裂させるかどうかを確認します。そうした場合、彼らは人間であるだけでなく、自分自身を検証するのに 30 秒かかりました。彼らにセッションIDを与えます。

そのセッション ID に好きなようにさせますが、リクエストが多すぎると、もう一度再生しないと続行できません。

score 5 · Accepted Answer

ボットを罰するためにTarpit （Wikipedia Article）を実装するアプリケーションの前にあるApacheサーバーにリバースプロキシを記述します。過去数秒間に接続したIPアドレスのリストを管理するだけです。単一のIPアドレスからの要求のバーストを検出し、応答する前にそれらの要求を指数関数的に遅延させます。

もちろん、NAT接続されたネットワーク接続を使用している場合、複数の人間が同じIPアドレスから来る可能性がありますが、ボットが妨げられるのに対して、人間が2mSから4mS（または400mS）の応答時間を気にする可能性はほとんどありません。遅延がかなり速く増加することによって。

score 5 · Accepted Answer

すでにいくつかの他の/より良い解決策が投稿されていますが、完全を期すために、これについて言及したいと思います:

主な関心事がパフォーマンスの低下であり、真のハンマーを検討している場合、実際には DoS 攻撃に対処しているため、それに応じて対処する必要があります。一般的なアプローチの 1 つは、1 秒/1 分などの数の接続後に、ファイアウォール内の IP からのパケットを単純にドロップすることです。たとえば、標準の Linux ファイアウォールである iptables には、標準的なオペレーションマッチング関数「hashlimit」があり、これを使用して時間単位ごとの接続要求を IP アドレスに関連付けることができます。

ただし、この質問はおそらく、最後の SO ポッドキャストで言及された次の SO 派生物により適していると思われますが、まだ公開されていないため、答えても問題ないと思います :)

編集:
novatrust が指摘したように、実際には顧客に IP を割り当てていない ISP がまだ存在するため、事実上、そのような ISP のスクリプト顧客は、その ISP からのすべての顧客を無効にします。

score 4 · Accepted Answer

キャプチャを使用しても、ボットを完全に防ぐことはできません。ただし、ボットを作成して維持するのは面倒なので、数を減らすことができます。特に、ボットを毎日更新するように強制することで、ほとんどの人が興味を失うことになります。

ボットの作成を困難にするためのいくつかのアイデアを次に示します。

javascript関数を実行する必要があります。Javascriptを使用すると、ボットを作成するのが非常に面倒になります。実際の非javascriptユーザーを許可するためにjavascriptを実行していない場合は、キャプチャが必要になる可能性があります（最小限）。
フォームに入力するときにキーストロークの時間を計ります（これもjavascriptを使用します）。それが人間のようでないなら、それを拒絶してください。ボットでの人間のタイピングを模倣するのは苦痛です。
新しいランダムな値でフィールドIDを毎日更新するコードを記述します。これにより、ボットを毎日更新する必要がありますが、これは苦痛です。
毎日フィールドを並べ替えるコードを記述します（明らかに、ユーザーにとってランダムではない方法で）。彼らがフィールドオーダーに依存している場合、これは彼らをつまずかせ、再び彼らのボットコードに毎日のメンテナンスを強制します。
さらに進んで、Flashコンテンツを使用することもできます。Flashは、ボットを作成するのに完全に苦痛です。

一般的に、彼らを阻止するのではなく、彼らのためにより多くの仕事をするという考え方を取り始めれば、あなたはおそらくあなたが探している目標を達成することができます。

score 4 · Accepted Answer

RSS フィードを提供して、帯域幅を消費しないようにします。
購入するときは、正確に探しているものに応じて、最大 45 秒程度のランダムな時間、全員を待機させます。正確には、タイミングの制約は何ですか?
抽選のために全員に 1 分間名前を記入してもらい、無作為に人を選びます。これが最も公平な方法だと思います。
アカウントを監視し (セッションに何回か含めて保存しますか?)、人間の速度のしきい値を下回っているように見えるアカウントに遅延を追加します。これにより、ボットは少なくとも速度を落として人間と競争するようにプログラムされます。

score 4 · Accepted Answer

未登録ユーザー向けのすべての製品発表を 5 分間遅らせます。カジュアルなユーザーはこれに気付かず、非カジュアルなユーザーはとにかく登録されます。

score 3 · Accepted Answer

ほとんどの純粋に技術的なソリューションはすでに提供されています。したがって、問題の別の見方を提案します。

私が理解しているように、ボットはあなたが販売しているバッグを本当に購入しようとしている人々によって設定されています。問題は -

ボットを操作しない他の人々は、購入する機会に値します、そしてあなたは限られた量のバッグを提供しています。
あなたはあなたのサイトに人間を引き付けて、ただバッグを売りたいです。

ボットを回避しようとする代わりに、潜在的なバッグ購入者が電子メールまたはSMS更新をサブスクライブして、販売が行われるときに通知を受け取ることができるようにすることができます。1〜2分前倒しで開始することもできます（販売が開始され、ランダムに生成され、メール/ SMSで送信される特別なURL）。

これらのバイヤーがあなたのサイトにいるのを買いに行くとき、あなたはサイドバナーなどであなたが望むものを何でも彼らに見せることができます。ボットを実行している人は、単に通知サービスに登録することを好みます。

ボットランナーは、購入をより早く完了するために、通知でボットを実行する場合があります。そのためのいくつかのソリューションは、ワンクリック購入を提供することができます。

ちなみに、ユーザーは登録されていないとのことですが、これらのバッグを購入するのはランダムな購入者ではなく、これらの販売を楽しみにしている人々のようです。そのため、彼らはバッグを「勝ち取る」ことを試みる際に利点を得るために登録することをいとわないかもしれません。

本質的に、私が提案しているのは、問題を技術的な問題ではなく、社会的な問題として見ようとすることです。

アサフ

score 3 · Accepted Answer

着信 IP をチェックすることからあなたが主張する大きな負担を感じていません。それどころか、クライアントの 1 人のために、HTTP アクセスログを 5 分ごとに分析するプロジェクトを行いました (リアルタイムで行うこともできましたが、彼は何らかの理由でそれを望んでいませんでしたが、私には完全には理解できませんでした)。アドレスが正当な検索エンジン (google、yahoo など) に属していると確認できない限り、過剰な数のリクエストを生成する IP アドレスからの接続をブロックするファイアウォールルールを作成します。

このクライアントは Web ホスティングサービスを実行しており、合計 800 ～ 900 のドメインを処理する 3 台のサーバーでこのアプリケーションを実行しています。ピークアクティビティは 1 秒あたり 1000 ヒットの範囲内にあり、パフォーマンスの問題は一度もありません。ファイアウォールは、ブラックリストに登録されたアドレスからパケットをドロップするのに非常に効率的です。

そして、はい、このスキームを打ち負かす DDOS 技術は間違いなく存在しますが、彼はそれが現実の世界で起こるのを見ていません。それどころか、サーバーの負荷が大幅に軽減されたと彼は言います。

score 3 · Accepted Answer

私のアプローチは、非技術的な解決策に焦点を当てることです (そうしないと、軍拡競争に参加して負けるか、少なくとも多くの時間とお金を費やすことになります)。請求/発送の部分に焦点を当てたいと思います.同じ住所への複数の配達を見つけるか、単一の支払い方法への複数の請求によってボットを見つけることができます. 数週間にわたって複数のアイテムでこれを行うこともできるため、ユーザーが以前のアイテムを取得した場合 (非常に迅速に応答することによって)、今回は何らかの「ハンディキャップ」が割り当てられる可能性があります。

これには、おそらく、運が良ければおしゃべりを購入する人々の輪が広がるという副作用もあります（有益だと思いますが、あなたの場合はマーケティング的に間違っている可能性があります）.

score 2 · Accepted Answer

DoS を防止することは、@davebug が上で概説した目標の 2 番目「ボットによって速度が低下しない速度でサイトを維持する」を無効にしますが、1 番目の「スクリプトを使用しない人間にアイテムを販売する」を解決する必要はありません。

スクリプターは、人間が注文フォームを通過するよりも速く、過度の制限のすぐ下でスケートをするために何かを書くことができると確信しています.

score 2 · Accepted Answer

よし、スパム送信者は一般の人々と競い合って「がらくたの沼地」のオークションに勝とうとしているのでしょうか? 次のオークションを文字通りの「がらくた」にしてみませんか？スパム送信者は、犬の犬がいっぱい入ったバッグに大金を払い、私たちは皆、彼らを笑いものにします。

score 2 · Accepted Answer

問題をひっくり返してみましょう - あなたが実際の人に買ってもらいたいものをボットが買っている場合、あなたが実際の人に買ってほしくないものをボットが買う可能性を実際に作ってみませんか。

スクレイピングボットが実際の状況であると考える非表示の html がランダムに発生する可能性がありますが、実際の人には表示されません (実際の人には視覚障害者が含まれることを忘れないでください。スクリーンリーダーなども考慮してください)。これは、途方もなく高価なものを購入するために移動します（または、実際の購入はしませんが、禁止リストに入れるための支払いの詳細を取得します）。

ボットが「購入する」ではなく「ユーザーに警告する」ように切り替えたとしても、十分な誤報を得ることができれば、人々にとって十分に価値のないものにすることができるかもしれません (すべての人ではないかもしれませんが、詐欺のいくつかの削減はまったくないよりはましです）気にしないでください。

score 2 · Accepted Answer

余談ですが、問題は、ユーザーが期待する動作がボットに非常に似ていることです (大きな波に乗って、認証されずに、すべてのボタンをクリックしてください:))。そのため、Captcha が唯一のチューリングテストである可能性があります。それを識別することができます:)）。

score 2 · Accepted Answer

ここで重要なことは、システムを変更してサーバーの負荷を取り除き、ボットがゲームをしている、または戦略を修正することをボットロードに知らせずに、ボットががらくたの袋に勝つのを防ぐことです. 最後に何らかの処理をせずにこれを行う方法はないと思います。

そのため、ホームページにヒットを記録します。誰かがそのページにアクセスするたびに、接続が最後のヒットと比較され、接続が速すぎる場合は、オファーのないバージョンのページが送信されます。これは、ホームページのキャッシュバージョンを提供するだけのサーバーにボット (速すぎるヒット) を送信する、ある種の負荷分散メカニズムによって実行できます。実際の人は良いサーバーに送られます。これにより、メインサーバーの負荷が軽減され、ボットはまだページが正しく提供されていると認識できます。

なんらかの方法でオファーを断ることができればなおさらです。その後、偽のサーバーで引き続きオファーを行うことができますが、ボットがフォームに記入すると、「申し訳ありませんが、あなたは十分に迅速ではありませんでした.

score 2 · Accepted Answer

1 分間に非常に多くのリクエストを行うタイムブロックユーザーエージェント。たとえば、誰かが 10 分間、5 秒ごとに正確にページをリクエストしている場合、その人はおそらくユーザーではありません... しかし、これを正しく行うのは難しいかもしれません。

アラートがトリガーされた場合は、すべてのリクエストを DB-IO をできるだけ少なくして静的ページにリダイレクトし、X 分後に許可されることを知らせるメッセージを表示します。

おそらくこれをページのリクエストにのみ適用し、メディア (js、画像など) のすべてのリクエストを無視する必要があることを付け加えておくことが重要です。

score 2 · Accepted Answer

注文を出しているスクリプターがいることをどのように知っていますか?

あなたの問題の核心は、スクリプト作成者を正当なユーザーから分離できないため、それらをブロックできないことです。

この質問に答える方法がある場合は、スクリプターをフィルター処理するために使用できる一連の特性があります。

score 1 · Accepted Answer

事前の警告：

私はスクリプトの知識がありません。私はここで他のコメントの多くを読んでいません。

私は今朝のWootの説明からこれに出くわしました。wootサイトの適度なユーザー（およびBOCの2回の手動購入者）からのいくつかのコメントが役立つかもしれないと思いました。

Wootは、コマースサイトであり、忠実なユーザーがいる目的地でもあるというユニークな立場にあり、そのバランスの繊細さを理解しています。しかし、個人的には、Crap-CAPCHA（「CRAPCHA」-どういうわけか、私が最初にそのギャグを作ったのではないかと思います）がユーザーに与える「ユーザーへの悪影響」についての懸念はかなり誇張されていると思います。ユーザーとして、私は自分が人間であることを証明できれば幸いです。そして、私はWootがプロセスを楽しく面白くし、全体的なエクスペリエンスに統合することを信頼しています。

これは「軍拡競争」につながるのでしょうか？わからないが、それは助けになるだけだ。たとえば、購入する重要な情報が製品の画像に含まれている、または製品の説明に（毎回異なる方法で）暗示されている場合、スクリプトで実行できる最善の方法は、C-wordの検出時に購入ページを開くことです。。実際、これは問題ないと思います。オンラインである必要があり、先着順が適用されます。Wootalyzerや同様のツールは、睡眠中や仕事中に購入を自動化するのではなく、 認知度を高めるだけです。

これを理解して頑張ってください、そして良い仕事を続けてください。

JGM

score 1 · Accepted Answer

各ユーザーにRSAキーを販売するのはどうですか:)ねえ、彼らがWoWのためにそれを行うことができれば、皆さんはそれを行うことができるはずです。

私は私の答えにBoCを期待しています;）

score 1 · Accepted Answer

まず第一に、テクノロジーを使ってテクノロジーを打ち負かそうとしないでください。

あなたの問題：

サイトの使いやすさ
サイトをエキサイティングで楽しいものにするリスト
スクリプト作成者が原因でサーバーに負荷がかかります。

あなたの目標：

ボットによって遅くならない速度でサイトを実行し続けます。
スクリプトを作成していない人間にアイテムを販売します。
「通常の」ユーザーを、人間であることを証明するために完了するタスクに煩わせないでください。

目標1：ボットによって遅くならない速度でサイトを実行し続ける。

これは実際には非常に簡単です。他の誰かにページをホストしてもらいます。サーバーでホストされているフロントページの代わりに、Amazon S3/Akamaiにページをホストさせます。とにかく、ページのほとんどは「静的」です。5分ごとにページを再生成するため、より動的なアイテムが更新されます。（地獄、必要に応じて1分ごとに再生成します）。しかし、ボットはサーバーにアクセスしていません。確かに負荷をかけることができるAkamaiのCDNにアクセスしています。

もちろん、RSSフィードでもこれを行います。他のサービスが帯域幅/負荷のヒットを処理できない理由はありません。関連するメモとして、すべての画像をアカマイなどが提供しています。なぜヒットするのですか？

目標2：スクリプトを作成していない人間にアイテムを販売する

私は、スクリプトが実際の利点をもたらさないようにするという他の人たちに同意します。ただし、スクリプティングは熱心な顧客の兆候でもあるため、あなたもa*holeになりたくありません。

だから私は彼らに買わせるが、彼らに膨らんだ金額を支払わせる（またはより好ましくは）他の人がチャンスを得ることができるように彼らを遅くするだけだと思います。

したがって、ユーザーがサイトにアクセスするたびに、29.99ドルでがらくたの袋を提供し、ランダムな速度の低下または値上げでタイマーを使用します。忍耐強い場合に価格が下がるかどうかを人間に伝える画像またはその他の指標を用意します。

ユーザーには「今すぐ購入」があります。価格/＃アイテムが欲しいものであることがわかったときにクリックするボタン。

例：

ユーザー：

0秒$29.99（1アイテム）画像の内容：「低価格でお待ちください！」
7秒$31.99（1アイテム）画像の内容：「低価格でお待ちください！」
13秒$27.99（1アイテム）画像によると：「もっとうまくやれるように！」
16秒$1.99（0アイテム）画像によると：「私たちに何かを無料で支払うのはおかしいでしょう！」
21秒$4.99（2つのアイテム）画像によると：「それは良くなっています！」
24秒$4.99（tres itemos）画像によると：「それ以上に良くなることはありません！」
26秒$8.99（2アイテム）画像によると：「もっとうまくやれるように！」

繰り返す....

徐々に締めるサイクルで、正しい「$ 4.99（tres itemos）」が表示される時間が長くなります

ボットが更新を押すと、サイクルが再開されます。ユーザーが間違ったアイテム数/価格を見逃して選択した場合は、その価格で購入できるようにするかどうかを決定します。

たとえば、「使いすぎ」の場合、3つのアイテムに$ 24.99を支払い、wootは3つのアイテムに$ 4.99を請求するだけで、次のwootの購入から$20のクーポンを含めます。

目標3：「通常の」ユーザーを人間であることを証明するために完了するタスクに煩わせないでください。

あなたはここで論理的な誤謬を作っています。チューリングテスト（ http://en.wikipedia.org/wiki/Turing_test）は刺激的である必要があると想定しています。本当じゃない！

ここにいくつかのアイデアがあります：

ゲームを作成します。ゲームをプレイすることの報酬は、次の注文で5ドルの割引クーポンです。
2人のランダムなユーザーをペアにして、お互いにチャットさせます。各ユーザーは、他のユーザーに2つの質問に答えるように指示されます：「あなたの髪の色は何色ですか？」と「次の週末は何をしますか？」一部のユーザーは、wootランダムセンテンスジェネレーターとペアになります。次に、各ユーザーは、他のユーザーが人間であるかどうかを尋ねられます。ユーザーがwootランダムセンテンスジェネレーターが人間であると言った場合は、「いいえ、私はそうではなく、あなたも火星出身かもしれません。もう一度やり直しますか？」と返信します。
割引クーポンを取得するためにユーザーが障害物コースを操作する必要があるシンプルなフラッシュゲーム。
彼らがどの都市にいるかを尋ねます。IPアドレスを逆にジオコーディングして、それらがほぼ正しいかどうかを確認します。
ばかげた質問をする-「ジョン・マケインは素晴らしい大統領だと思いますか？」「あなたの運転免許証には誰の写真がありますか？」

あなたが本当にやりたいのはスクリプトキディーを遅くすることだけなので、3回だけ尋ねてください。

score 1 · Accepted Answer

私はここでOPに同意します-キャプチャはお願いしません-それは物事を行うための非常に面倒な方法ではありません.

まず、いくつかのボットトラップを設定します。ボットが賢くないように見えるようにボットをトラップするために、ホームページで BOC についてもっと頻繁に言及したいと思います。- そのため、キーワードをスキャンするだけのボットはトラップされます。

ただし、ここでの本当の問題は 2 つあると思います。まず、対処する必要があるパフォーマンスの問題です。現在、ボットが問題を引き起こしていますが、対処すべきパフォーマンスの問題があることを示しています。

第二に、利益を得るために本物のがらくたをシフトするビジネスチャンスです。したがって、全体的な woot スタイルを維持し、「ボットをチェックします。ボットであると思われる場合は、botcrap のボックスを取得します」と述べます。

ボットチェックは、ボットトラップ、IP 番号、Cookie、セッション、ブラウザ文字列などを使用して、販売が行われた後にオフラインで行われます。誰がボットクラップを取得するかを判断するために、購入者から得たデータを使用していくつかの深刻な分析を行います。botcrap を出荷することにした場合は、通常のがらくたを解放して他の人に売ることができます。

score 1 · Accepted Answer

いくつかのアイデア:

簡単です。「Random Crap」という名前は付けないでください。アイテムの名前を毎回変更して、ボットが識別しにくくするようにします。彼らはまだ 1.00 ドルの商品を探しているかもしれません。その場合は、時々 1 ドルのガムを数分間売ることをお勧めします。5ドルの送料は、あなたの価値があるはずです.
難しい: ユーザーに余分なことをさせないでください。ユーザーのコンピューターに余分なことをさせてください。大量の処理能力を必要とする集中的な計算を実行する JavaScript 関数 (たとえば、1,000 万分の 1 の素数) を作成し、ユーザーのコンピューターにその値を計算させて、注文を受け入れる前に返します (おそらく、"ご注文」URL）。BoC ごとに関数を変更して、ボットが結果を事前に計算してキャッシュできないようにします (できるようにします)。計算のオーバーヘッドは、ボットの速度を低下させて、ボットを背後から遠ざけることができます。少なくとも、サーバーへのヒットが遅くなり、呼吸できるようになります。
- え

score 1 · Accepted Answer

これが私の見解です。ボットの所有者の ROI を攻撃して、不正行為を行う代わりに、ボットの所有者が望んでいる合法的なことを実行するようにします。彼らの視点から見てみましょう。彼らの資産は何ですか？どうやら、無制限の数の使い捨てマシン、IP アドレス、そしておそらく無意味な作業を喜んで行う熟練していない多数の人間でさえあります。彼らは何を望んでいるのか？他の正当な人々がそれを得る前に、あなたが提供している特別な取引を常に得ること。

良いニュースは、レースに勝つための時間枠が限られていることです。そして、彼らが持っているとは思えないのは、あなたが取引を開始した瞬間にあなたのサイトをリバースエンジニアリングするために電話をかけている無数の賢い人々です. したがって、彼らには理解するのが難しい特定のフープをジャンプさせることができれば、正当な顧客にとっては自動的に（彼らはそこにあることさえ知らないでしょう）、彼らの努力を遅らせることができます。あなたのホットディールを手に入れようと必死になっている膨大な数の実在の人々。

最初のステップは、認証の概念を非バイナリにすることです。つまり、特定のユーザーに対して、そのユーザーが実在の人物またはボットである可能性が割り当てられます。この可能性を構築するために多くのヒントを使用できます。その多くは、このスレッドで既に説明されています: 疑わしいレートアクティビティ、IP アドレス、外国の地理位置情報、Cookie などです。私のお気に入りは、正確なバージョンに注意を払うことです。彼らが使用しているウィンドウの。さらに重要なことは、長期的な顧客に強力なヒントで認証するための明確な方法を提供できることです: サイトに参加する、購入する、フォーラムに投稿するなど。特売品を見る時が来ると、わずかな利点があります.

認証の決定を求められたときはいつでも、この可能性を利用して、話している相手のコンピューターが必要とするものを提供する前に、多かれ少なかれ仕事をさせます。たとえば、サイトの一部の JavaScript では、クライアントがバックグラウンドで計算コストの高いタスクを実行する必要があり、そのタスクが完了したときにのみ、特別な取引についてクライアントに通知します。通常の顧客の場合、これは非常に迅速かつ簡単に行うことができますが、詐欺師にとっては、一定のカバレッジを維持するために、より多くのコンピューターが必要になることを意味します (各コンピューターはより多くの作業を行う必要があるため)。次に、上記の確率スコアを使用して、彼らがしなければならない仕事の量を増やすことができます。

この遅延が公平性の問題を引き起こさないようにするために、個人のコンピューターからの現在の時刻を含む何らかの暗号化タスクにすることをお勧めします。詐欺師はいつ取引が開始されるかわからないため、何かをでっち上げることはできず、実際の時刻に近いものを使用する必要があります (取引開始前に来ると主張する要求は無視してかまいません)。）。次に、これらの時間を使用して、実際の人々が何も知る必要なく、先着順ルールを調整できます。

最後のアイデアは、新しい取引を投稿するたびに (そしてランダムに) 作業を生成するために必要なアルゴリズムを変更することです。それを行うたびに、通常の人間は影響を受けませんが、ボットは機能しなくなります. 彼らはリバースエンジニアリングに取り組むために人間を雇わなければならないでしょう。彼らが間違ったことをしているという警告を受け取らないように、彼らが正しい結果を提出したかどうかを決して伝えない方が良いでしょう. この解決策を打ち破るには、本物のブラウザー (または少なくとも本物の JavaScript インタープリター) を実際に自動化する必要があります。そうすると、詐欺のコストが本当に高くなります。さらに、実際のブラウザを使用すると、このスレッドの他の場所で提案されているようなトリックを実行できます。たとえば、各エントリのキーストロークのタイミングを計ったり、他の疑わしい動作を探したりすることができます.

そのため、以前に見たことのある人 (共通の IP、セッション、Cookie など) に対しては、各リクエストをもう少し高価にする方法があります。つまり、詐欺師は常に、これまで見たことのない新しいコンピューター/ブラウザー/IP の組み合わせという、最も困難なケースを提示したいと考えています。しかし、ボットが正しく機能しているかどうかを知ることさえできるようにするために余分な作業を行うことで、これらの貴重なリソースの多くを無駄にすることになります。それらは実際には無限にあるかもしれませんが、それらを生成するにはコストがかかります。また、ROI 方程式のコスト部分を押し上げることになります。最終的には、あなたがやりたいことをするだけで、彼らにとってより有益になるでしょう:)

お役に立てば幸いです。

エリック

score 1 · Accepted Answer

ハイテクとローテクの 2 つのソリューション。

まずハイテク: ボットは最初の数ミリ秒でそれらの多くを取得するため、BOC の製品は数秒で売り切れます。したがって、ボットを倒そうとする代わりに、ボットがスキャンしているもの、つまりゴミ袋を売りましょう。もちろん、価値のないがらくた：曲がったペーパークリップとロージー・オドネルの汚された写真。次に、一度に数秒間、サーバーにランダムな遅延を組み込みます。販売が続くにつれて、販売された製品の実際の価値は増加しますが、販売価格は増加しません。そうすれば、最初の購入者 (最初の数ミリ秒のボット) は支払った額よりもはるかに価値の低いもの (ブラウンオニオンケーキ?) を手に入れ、次の購入者 (より遅いボットまたはより速い人間) は目立たないが、購入価格に見合う価値のあるものを手に入れることができます (委託購入？）、最後の購入者 (ほぼすべての人間) は、購入価格よりも価値のあるものを手に入れることになります (シャンパンを割る?)。その薄型テレビは、BOC が最後に購入したものに含まれている可能性があります。

あまりにも長く待つ人は逃しますが、同時にあまりにも早く購入する人は夢中になります. 秘訣は、ある程度の時間待つことです...しかし、あまり長くはありません。ある程度の運も関係していますが、それはあるべき姿です。

ローテクな解決策は、BOC の名前を人間には解釈できるがボットには解釈できない名前に変更することです。排泄物のワインスキン？臭いの入った袋？さまざまな商品に隣接するトポロジー的に平坦な表面? 同じ名前を 2 回使用しないでください。わずかに異なる写真を使用し、商品説明で実際に販売されているものを説明してください。

score 1 · Accepted Answer

コンテンツを CAPTCHA にしてみませんか?

賞品を表示するページでは、常に同じ名前の同じ場所に画像ファイルを配置し、セールが行われているときは、賞品を宣伝するテキストなどを含む画像を動的に生成してロードします。オンには、サイトとうまく統合されるデフォルトの画像がいくつかあります。CAPTCHA と同じ概念のようです...ボットが画像の意味を理解できない場合、「勝つ」ことはできません。

score 1 · Accepted Answer

上で示唆したように、フォームに格納された結果の期待値の事前計算されたハッシュを使用して、非キャプチャフォームでいくつかの作業を行いました。このアイデアは、2 つの Wordpress スパム対策プラグイン ( WP-MorphとWP-HashCash) で機能します。唯一の欠点は、クライアントブラウザが JavaScript を解釈できる必要があることです。

score 1 · Accepted Answer

ハッシュキャッシュを使用します。

Hashcash はサービス拒否対策ツールです。現在の主な用途は、ハッシュキャッシュユーザーがコンテンツベースおよびブラックリストベースのスパム対策システムによって電子メールを失うのを防ぐことです。

score 1 · Accepted Answer

私はおそらく問題を完全には理解していませんが、このアイデアが思い浮かびました。AJAX を使用して動的コンテンツを一定の間隔で描画および更新し、更新を使用してページ全体の読み込みを意図的に遅くします。

たとえば、ページ全体が最初にアクセスされたときに描画するのに 15 秒かかるようにし、その後、設定された時間 (たとえば 5 秒) 後に AJAX を使用して動的コンテンツが自動的に更新されるようにします。ページ全体をリロードすることは、大きな欠点となります。ページには定期的に新しい情報 (広告を含む) が表示される場合がありますが、リロードを使用してページ全体を再描画すると、かなり遅くなります。

スクリプトキディが AJAX クエリを見つけて自動化することは可能ですが、同じ IP からのこれらのリクエストを非常に簡単にレート制限することもできます。標準的な人間のユーザーがブラウザからこれらのリクエストを開始する一般的な方法はないため、同じ IP からの AJAX URL への高レートのリクエストが何らかの自動システムによって開始されることは明らかです。

score 1 · Accepted Answer

これがまだ提案されているかどうかはわかりませんが、ボットの IP のリストを保持するのではなく、すべてのページ要求でスキャンする必要があるため、追跡するために Cookie またはセッション変数を設定してみませんか?ボット？PHP での例を次に示します。

<?php
// bot check
$now = microtime(true);
// bot counter var
$botCounter = 0;
if (array_key_exists('botCheck_panicCounter', $_REQUEST))
{
  $botCounter = $_REQUEST['botCheck_panicCounter'];
}

// if this seems to be a bot
if ($botCounter > 5)
{
  die('Die()!!');
}

// if this user visited before
if (array_key_exists('botCheck_lastVisit', $_REQUEST))
{
  $lastVisit = $_SESSION['botCheck_lastVisit'];
  $diff = $now - $lastVisit;

  // if it's less than a second
  if ($diff < 1)
  {
    // increase the bot counter
    $botCounter += 1;
    // and save it
    $_REQUEST['botCheck_panicCounter'] = $botCounter;
  }
}

// set the var for future use
$_SESSION['botCheck_lastVisit'] = $now;

// ---------------
// rest of the content goes here
?>

構文エラーはチェックしませんでしたが、お分かりいただけたでしょうか。

score 1 · Accepted Answer

私は時々本当に「がらくた」のがらくたの袋を売ることについて言った上記のポスターに同意します.

あなたは、提供しようとしているテクノロジーによってサーバー的に制限されたビジネスモデルを思いついたようです。しかし、ほとんどの技術志向の個人のように (批判ではありません。結局のところ、それがこのサイトの目的です)、技術的な解決策を考え出そうとしています。しかし、これはビジネス上の問題です。これはテクノロジーの失敗によって引き起こされていますが、それはテクノロジーが答えであるという意味ではありません。そして、誰もが思いつく (そして多くの選択肢がある) ほとんどすべてのソリューションは、最終的には、あなたの「がらくたの袋」を「自動購入」することを決定した人によって迂回されます (より良い短い説明が必要なため)。

私見では、あなたは間違った人に間違った質問をしていて、間違った解決策に多くの時間とリソースを浪費することになります.

score 1 · Accepted Answer

スクリプトが読みにくい価格にすることもできます。これは画像に変換することで最も簡単に実現できますが、テキスト認識アルゴリズムを使えばこれを回避できます。十分なスクリプターがこの問題を回避できれば、キャプチャのようなものをこの画像に適用することもできますが、明らかにユーザーエクスペリエンスが犠牲になります。画像の代わりに、価格をフラッシュアプリに表示することもできます。

別の方法として、レンダリングに影響を与えない方法でページの HTML を「シャッフル」する方法を考案することもできます。頭の中で良い例を思いつくことはできませんが、何とか実行可能であると確信しています。

score 0 · Accepted Answer

画像に表示される遅延をユーザーが待たなければならない遅延ページはどうですか？

画像で指定された時間内にクリックした場合にのみ、ページからの順序付けを行います。画像は、アニメーションGIF、非常に小さなJavaScript、またはフラッシュタイマー内でカウントダウンを実行している可能性があります。

制限時間外に詳細ページにジャンプすると、前の回答で説明したように高価なアイテムが表示されます。

score 0 · Accepted Answer

ここにはたくさんの提案がありますので、これがすでに投稿されている場合はご容赦ください。

私が最初にすることは、注文を2段階のプロセスにすることです。最初のステップでは、IPアドレスのログ記録中にGUIDを返します。2番目のステップでは、GUIDを受け取り、ログに記録されたIPアドレスと比較します。サイトをスパムしているIPアドレスをブロックすること（つまり、人間が更新をクリックするよりも速い）と併せて、この手法はスパマーが正常に購入するのを阻止し、それによって1と3を解決する可能性があります。

2番目の項目は問題がありますが、通常のユーザーのIPアドレスの実行リストを保持し、新規参入者のトラフィックを抑制します。これにより、初めての訪問者とダイヤルアップユーザー（IPアドレスの変更による）が寒さの中に置かれる可能性がありますが、リピートビジネスを優先することで、悪い状況を最大限に活用していると思います...そしてダイヤルアップユーザーはそうですとにかくスパマーがいなくても、彼らが「勝つ」かどうかは疑わしい。

score 0 · Accepted Answer

フラッシュをお勧めするとは思ってもみませんでしたが、フラッシュはどうでしょうか。取引時間の有無にかかわらず、サーバーに非同期の暗号化されたコンテンツをフラッシュファイルシグナリングに送信させます。応答が同じサイズの取引であるか、取引がない限り、ボットはそれがどちらであるかを判断できません。

より一般的なレベルでは、スクリプト化されたボットにはない、人間とブラウザーが持つリソースに焦点を当て、人間/ブラウザーにとっては簡単で、ボットにとっては難しいことを利用する必要があります。キャプチャは明らかにこれを行うための単純な試みですが、あなたが言うようにあなたのサイトには適していません。Flashは大量のボットを排除し、実際のブラウザーを駆動する（遅い）ボットのみを残します。ユーザーが適切な場所をクリックするだけでよい場合、ソリューションはキャプチャよりもはるかに簡単になる可能性があります。

人間の超並列画像処理能力を活用してください！

score 0 · Accepted Answer

javascriptを必須にする場合は、ハッシュキャッシュスキームを使用して、たとえば、リクエストごとに最大30秒相当のクライアント側の計算を要求できます。（もちろん、iPhoneでは5分、30台のコンピューターのボットネットでは1秒になる可能性があります。重大な欠点です。）

（難読化された）javascriptまたは（gag）flashを使用してページを生成することにより、スクレイピングをより困難にすることもできます。

目に見えない（CSSとjavascriptを介して）ランダムながらくたリンクを持つボットをトロールすることもできます。

「ボットのような」IPアドレスを（レートおよびハニーポットリンクへのアクセスによって）検出し、それらを特別なサーバー（たとえば、「ビザによる検証」などの追加のCC検証を備えたサーバー）または単にキャプチャを備えたサーバーにリダイレクトできます。）。

しかし、実際には、それは軍拡競争です。:)そして、キャプチャを超えて最終的にエスカレートする必要があるかもしれません。

先着順のモデルから、ボットが実際の買い物客に比べてそれほど大きなアドバンテージを持たない宝くじモデルに変更してみませんか？

score 0 · Accepted Answer

想定される交渉不可：

最初の画面は、完全にシンプルでオーバーヘッドの少ないHTMLである必要があります。クリックするボタン、または「クラップが欲しい」を明確に示すための同等のボタンを1つ簡単に識別できます。最悪の場合を想定しているため、ボットと非ボットの組み合わせからのDOS攻撃に相当するものがあります。すべて、最初にサイトをクリックします（識別可能性の範囲内）。それでは、キャッシュや良性のエコーボットなどからできるだけ早くこれらを配りましょう。

（注：ウーターに関する限り、これはとにかく起こることです。ユーザーにとってはウートと同じように苦痛です。したがって、最初の画面の取得を吸収または軽減するのに役立つものはすべて、関係する3者全員の利益になります。）

そうすれば、このプロセスは、ボット以外の人にとっては現在よりも悪化する必要はなく、合法的な人にとっては追加の手順（または苦痛）はありません。（現在の設計に関する背景説明：現在のウーターは通常、すでにサインオンされているか、購入プロセス中にサインオンできます。新規購入者は購入時に登録する必要があります。したがって、登録が実質的に速く、まだログオンも速くありません。。）

がらくた販売を完了するには、トランザクション画面の進行をナビゲートする必要があります（たとえば、状況に応じて5、プラスまたはマイナス）。勝者は、完全なナビゲーションを完了した最初の人です。現在のプロセスは、5つの画面のシーケンス全体を最も速く完了したボット（または他の誰か）に報酬を与えます。しかし、進行全体は高速応答（つまりボット）に偏っています。

ボットが最初の画面で有利になることは間違いありません。そして、その時点から達成したエッジが何であれ、残りの画面を維持し、さらにボットネスが他の段階で提供する利点もすべて保持します。

Wootが最初の画面の後でキューイングプロセスを意図的に切り離し、その時点からのすべてのセッションを一連の固定された最小時間のステップにフィードした場合はどうなりますか？2番目の画面は、30秒が経過するまで表示されませんでした。提出後、以下の画面も同様です。最初の画面の後、キューで待機し（これはすでに真実です）、以前よりも長くはかからない方法で負荷を時間の経過とともに分散させると言われた場合、ボットは問題ないでしょう。堅牢で、ボットを取り除くのに役立ちます。この時点で、上記のボットのスピードバンプのいくつかを投入できます（DOMオブジェクトの微妙なバリエーションなど）。Wootがもう少し物事を制御しているという認識からの利益が役立つでしょう。

BOCの初期ヒットのはるかに高い割合が、再試行するのではなく、最初のヒット（またはそれに近い）でボットに不利なタイムクリティカルでないプロセスにつながる可能性がある場合、そのポイントを超えた実際の人々はより自信を持つことになります。確かにそれは現在の状況よりも敵対的ではないでしょう。通常のWoot-Offの状況下でも、常に発生しているbackground-noise-ambient-bot-rateが削減される可能性があります。そして、ボットはメインページを解雇し、お互いに（そして他のすべての人に）彼らが利点を持たないところでキューに座ります。

うーん...「アパートスレッド」という概念が思い浮かびます。パターンはおおよそ役に立つのだろうか？

ここでの便利なコアコンセプトは、最初の画面の後で、キュー内の累積合計時間を追跡し、標準に調整できることです。ボット軽減戦略として、非常に初期のセッションを5〜10秒でファッジするための柔軟性が少しあります。そうすることはおそらく検出できないでしょうが、ボット以外の購入ミックスがより豊富になるでしょう。事後にこのようなものを評価するのに役立つ統計があると確信しています。

楽しみのために、（少なくとも1回のウートオフで）これまでに見た中で最高の機能を組み合わせた独自のボットをまとめて、前日に全員に配布することができます。そうすれば、少なくとも誰もが平等に武装するでしょう。（それからアヒル...入ってくる...）

score 0 · Accepted Answer

ボットを処理する魔法の銀の弾丸はおそらくないでしょうが、これらの提案の組み合わせは、ボットを阻止し、より管理しやすい数に減らすのに役立つ可能性があります。
これらの提案のいずれかについて説明が必要な場合は、お知らせください。

アイテムを表す画像は、常に同じ画像名（ "current_item.jpg"など）にするか、リクエストごとに変わるランダムな名前にする必要があります。サーバーは現在のアイテムが何であるかを知っている必要があり、適切な画像を配信します。この画像には、画像サイズを比較するボットを減らすために、ランダムな量のパディングも必要です。（おそらく、より洗練されたボットを阻止するために、ある種の透かしを変更します）。
これらの画像からALTテキストを削除します。このテキストは通常、ページの他の場所にある冗長な情報であるか、一般的な代替テキストになります（「現在のアイテムの画像はここにあります」など）。
Bag of Crapが登場するたびに、説明が変わる可能性があります。「RandomCrap」、「BoC」、「Crappy Crap」など、さまざまな名前の間で（ランダムに）回転する可能性があります。
Wootは、「ランダムクラップ」価格でより多くのアイテムを提供することも、0.95ドルから1.05ドルの間のランダムな価格にすることもできます（公平を期すために、クラップが表示されるたびに1回だけ価格を変更します。ユーザーごとではありません）。
価格、説明、およびBoCを他のWootsと区別するその他の領域は、テキストではなく画像である可能性があります。
これらのフィールドは、Java（javaScriptではない）またはFlashの場合もあります。サードパーティのプラグインに依存していますが、ボットが便利な方法でサイトをスクレイプするのがより困難になります。
画像、Java、Flash、およびおそらく他のテクノロジーを組み合わせて使用することは、ボットにとってより困難にする別の方法です。管理者は多くの異なるプラットフォームを知っている必要があるため、これは管理が少し難しくなります。
この情報を難読化する方法は他にもあります。クライアント側のスクリプト（javascriptなど）とサーバー側の難読化（ランダムなイメージ名）を組み合わせて使用するのが、ユーザーエクスペリエンスに影響を与えることなくそれを行うための最も可能性の高い方法です。わかりにくいJavaやFlashなどを追加すると、一部のユーザーへの影響を最小限に抑えながら、より困難になります。
これらの戦術のいくつかを上記のいくつかと組み合わせます。ページが1分間にx回以上リロードされる場合は、画像名を変更するか（上記で提案された静的画像名がある場合）、2分前のキャッシュページを指定します。。
バックエンドでユーザー行動追跡を使用して実行できる非常に洗練されたことがいくつかありますが、あまり処理を必要としない場合があります。パフォーマンスへの影響を最小限に抑えるために、その作業を専用サーバーにオフロードできます。リクエストからデータを取得し、そのデータを処理できる専用サーバーに送信します。疑わしいボットが見つかった場合、その動作に基づいて、別のサーバー（フロントエンドルーティングファイアウォール、サーバー、ルーターなど、またはバックエンドWebサーバーまたはコンテンツサーバー）にフックを送信して、これらのユーザーにセキュリティを追加できます。これらのユーザーにJavaアプレットを追加したり、ユーザーからの追加情報を要求したりする場合があります（注文ページのすべてのフィールドに事前に入力したり、毎回異なるフィールドをランダムに空にしたりしないでください）。

score 0 · Accepted Answer

Woot.comの長年（4年）のユーザーであり、数袋のがらくたを購入しているので、現在私のガレージでスペースを取っている他の多くのアイテムの中で、ソリューションは全体的なWootテーマの一部である必要があるようです。

キャプチャを使用しますが、ユーモラスな静脈です。$ 1,000,000のプロモーションと同じように、自分を人として識別することでゲームを作成します。これは、過去にBOCの「売り切れ」を妥当な時間遅らせてきましたが、私のような人々は、クーポンコードを入力するためのかなり単純だがユーモラスなパズルを理解するためにスクランブルをかけています。

また、人々はサーバーエラーについて際限なく不平を言いますが、彼らは戻ってくるのをやめません。私の意見では、BOCのスリルの一部は、他にも何億もの人々がBOCを取得しようとしているという事実です。サーバーがエラーまたはファンキーなページをスローした場合、それは私が1500の製品の1つを取得しようとしているあまりにも多くの人々のグループのどこかにいることを示しています。

パズルの作成にできるだけ多くの創造性を注ぎ込み、それが十分に独創的である場合、他のすべての人にチャンスを与えるのに十分な時間、ボットを遅らせることになります。コードとしてキャプチャされたランダムな単語を組み込み、「I Want One」と購入ページの間に中間ページを配置します。これには、独自の人間の操作が必要です。ボットは、何が起こる必要があるかがわかるまで、そこで停止します。

•退屈な実装をしておらず、キャプチャを読むのが非常に難しい場合があります•プロセスをより楽しくしました•実際の安全な購入サーバーの負荷を軽減しました•ユーザーに必要なトレーニングを行いますBOCを取得するために何かを「実行」する•中間ページでボットを停止し、ほとんどの人が少なくとも面白いがそれほど難しいパズルを理解する機会がなくなるまで、ボットの購入を遅らせます。
•ランダムであることはBOCのすべてであるため、ランダムで変化するパズル/タスクは、BOCのピッチ全体に単純に適合します。

実験すると、中間ページの背後にあるテクノロジーがより高度になり、購入ページで使用するためにランダムな情報を取得できるようになります。以来

ボットの助けを借りずに、またはwootalyzer以外のスクリプトを購入しましたが、これは許容できる助けだと思います。2005年5月31日以降、7つのBOCを購入しました。私が手に入らなかった最高のものは、プリーズ・プリーズ・ミーBOCでした。B＆Dバッテリーも楽しかったですが、ボットを困らせることはなく、通常のユーザーを苛立たせただけだったと思います。

テクノロジーの問題に対する最善の解決策は、テクノロジーを増やすことではない場合があります。

score 0 · Accepted Answer

特定の問題（一般的な問題ではない）に対する潜在的な解決策は、ユーザーが「がらくた」を見たい場合にサインインすることを要求することです。たまたまログインしているユーザーにのみがらくたの賞品を表示します。他のすべてのアイテムは、これまでと同様に、ログインしていないユーザーが表示できるままにすることができます。次に、忠実なユーザーががらくたに最優先されます。

おそらく、実際のユーザーががらくたを見つける可能性を高めるためにこれが行われているという通知で、これをユーザーに通知する必要があることは明らかです。

特定の問題が特定の種類のアイテムを収集するボットである場合は、最も制限の少ない代替手段を採用し、その特定の攻撃に対してのみ防御します。このオプションは、気になるキャプチャやユーザビリティヒットを防ぎます。

ボットがログインしてスパム行為を開始した場合、ボットを強制的にログアウトさせてアカウントをロックすることができます。

彼らが袋を手に入れるためだけにそこにいる場合、彼らはかなり早く去り、あなたのページは大規模なヒットを受けません. 高度に技術的なソリューションは忘れてください。

score 0 · Accepted Answer

フロントページをイメージマップグラフィック (ラベルやタグなどのないすべて 1 つの画像) にしないのはなぜですか? ほぼすべてのデバイスで人間が読んで理解するのは簡単ですが、ボットが質問することは不可能です。本質的に、フロントページ全体をキャプチャにします。

score 0 · Accepted Answer

私が最初に思ったのは、ボットがあなたの Web ページをスクレイピングしているとあなたが言っているということでした。これは、ボットが HTML コンテンツだけを取得していることを示唆していると思われます。そのため、注文画面で (http ログから) オファー関連のグラフィックがボットから読み込まれたことを確認します。

score 0 · Accepted Answer

元の価格とそれよりもはるかに高い価格のどちらかをユーザーが選択できるようにします。ボタンをそれぞれの価格 (色、位置、おそらくボタンの「感情的な意味合い」) に関連付ける何らかの方法を見つける必要があります。これは、プログラムで決定するのが難しいものですが、ユーザーがボタンを価格に関連付けるだけで済みます。ユーザーにとっては簡単で直感的で手間がかかりませんが、スクリプト作成者にとっては難しく、さらに重要なことに、特に関連付けの方法を変える場合は危険です。

score 0 · Accepted Answer

フラッシュの使用についてはどうですか？

はい、私は Flash を使用することのオーバーヘッドを知っています。さらに、一部のユーザー (つまり、iPhone ユーザー) がバッグ・オ・クラップを購入できなくなるという事実は、これを有害にする可能性がありますが、Flash はスクリーンスクレイピングやスクリーンスクレイピングを防ぐように思えます。せめて難しくする。

私が間違っている？

編集して追加

私が以下に見つけたように、提出フォームにいくつかの「非表示」フィールドを含めることはどうですか:

実際、ベストプラクティスは、2 つの非表示フィールド (1 つは初期値あり、もう 1 つは初期値なし) を使用することです。両方のフィールドを無視できる珍しいボットです。1 つのフィールドが空白で、もう 1 つのフィールドが初期値であることを確認します。そして、それらを「非表示」フィールドにするのではなく、CSS を使用して非表示にします。

重要な { 表示: なし; }

次の 2 つのフィールドは変更しないでください。

ボットは「住所」のような名前のフィールドを好む傾向があります。この段落のテキストは、CSS 非対応のブラウザーを使用している少数のまれな人間のためのものです。それらを気にしない場合は、省略できます。

フォームを処理するロジックでは、次のようにします。

if (address2 == "xyzzy" and address3 == "") { /* 送信してもよい/ } else { /おそらくボットを持っている */ }

score 0 · Accepted Answer

お金の流れを追いかけてください。IP 側を追跡するよりもはるかに簡単です。ボットに多額の支払いを数回行わせます (白い背景に白いテキストとそのすべてのバリアントによるアナウンス)。これを慎重に準備し、ボットの長所である速度を十分に活用する必要があります。数秒間隔で数千の偽のアナウンスを試みましたか? 1 秒間に 10 回ヒットしている場合は、さらに速く進むことができます。彼らが買い続ける限りこれを維持したいので、これを開始したい日/週の瞬間について慎重に考えてください. 理想的には、彼らは支払いを停止するので、ケースを銀行に引き渡すことができます.
サイトが完全に生成されていること、および各ページアクセスが異なるページコンテンツ (html、javascript、および css) を返すことを確認してください。解析は生成よりも難しく、ボット開発者が処理できるよりも多くのバリエーションを簡単に組み込むことができます。コンテンツとその生成方法を変更し続けます。
ボットが変更にどれだけ迅速に適応できるか、できればボットがいるタイムゾーンを知る必要があります。それは 1 つ以上のボットネットですか、同じタイムゾーンにあるのか、別のタイムゾーンにあるのか、それとも世界中の開発者ネットワークですか? 反撃のタイミングを合わせたい。
現在の最先端のボットでは、人間がキャプチャに入力します (ポルノ/ゲームに対して提供されます)。
非常に速く反応するのは魅力的ではありません。
Ned Batchelder が説明するように、ハッシュとハニーポットを使用します。

[編集] ボットネットから防御できないというのは、単に真実ではありません。特に私の 2 番目の提案は、自動化された購入者に対する十分な防御を提供します。ただし、使用しているテクノロジーについて完全に再考する必要があります。Seaside でいくつかの実験を行うか、c で直接実行することをお勧めします。

score 0 · Accepted Answer

入りたい複雑さのレベルに基づいて、いくつかの解決策があります。

これらはすべて IP 追跡に基づいており、ボットネットやクラウドコンピューティングではややバラバラですが、大多数のボット作成者を阻止するはずです。Joe Random が大量のボットを自由に使える可能性は、どこかでダウンロードした Woot ボットを実行しているだけで、がらくたの袋を手に入れることができる可能性よりもはるかに低くなります。

プレーンオールドスロットリング

非常に基本的で大雑把なレベルでは、期間ごとに IP ごとにリクエストを調整できます。分析を行い、正当なユーザーが 1 時間に X 回以上サイトにアクセスしないことを確認します。1 時間あたりの IP あたりのリクエスト数をその数に制限すると、ボットはポーリング頻度を大幅に減らす必要があります。そうしないと、ボットは次の 58 分間ロックアウトされ、完全に盲目になります。これだけでボットの問題に対処することはできませんが、負荷が軽減され、正当なユーザーがアイテムを狙う可能性が高まります。

適応スロットリング

そのソリューションの変形として、負荷分散キューを実装することが考えられます。この場合、最近行われたリクエストの数がキュー内の位置に対してカウントされます。つまり、サイトを非難し続けると、リクエストの優先度が低くなります。がらくたの販売のようなトラフィックの多い状況では、ボットが待機し続けている間、接続の優先順位が高くなり、ページをより迅速に取得できるという点で、正当なユーザーはボットよりも有利になります。トラフィックが十分に減少して、その数が増えるまで。

行末キャプチャ

第 3 に、キャプチャに煩わされたくない場合でも、プロセスの最後、つまりトランザクションが完了する直前にキャプチャを行うことは、悪い考えではないかもしれません。その時点で、人々は販売にコミットしており、多少の不快感が加わったとしても、それをやり遂げる可能性があります. ボットが販売を完了するのを防ぎます。つまり、ボットができることは、少なくともあなたのサイトを叩いて、できるだけ早く販売について人間に警告しようとすることだけです. これで問題が解決するわけではありませんが、現在ボットが行っているよりも、人間が売り上げを得る可能性がはるかに高いことを意味します。解決策ではありませんが、改善です。

上記の組み合わせ

1 つの企業 IP の背後に複数の正当なユーザーが存在する可能性を考慮しながら、基本的で寛大なスロットリングを実装して、最も悪用的なボットを阻止します。カットオフ数は非常に高くなります - ボットがあなたのサイトに 10 倍/秒、つまり 1 時間あたり 216 万回のリクエストをヒットしたと述べましたが、これは、最大の企業ネットワークや共有 IP であっても、正当な使用法をはるかに超えていることは明らかです.

負荷分散キューを実装して、サーバー接続と帯域幅の共有よりも多くを占有するとペナルティを受けるようにします。これは共有企業プール内の人々に罰を与えますが、サイトの使用を妨げるものではありません。彼らの違反はあなたのボットよりもはるかにひどいものではないはずです.

最後に、1 時間あたりのリクエスト数のしきい値 (「自動的に接続を切断する」カットオフよりもはるかに低い可能性があります) を超えた場合は、ユーザーがキャプチャを使用して検証する必要があります。

そうすれば、合法的にサイトを使用していて、1 時間あたり 84 リクエストしかないユーザーは、非常に興奮している場合でも、サイトの速度低下の変化にまったく気付かない. しかし、ジョー・ボッターはジレンマに陥っています。彼は次のいずれかを実行できます。

現在の動作でリクエストクォータを使い果たし、サイトにまったくアクセスできなくなるか、または
リクエストクォータを超えない程度にリクエストを送信すると、トラフィックレベルが低くてもリアルタイムの情報が得られますが、トラフィックが多い時間帯にはリクエスト間に大幅な遅延が発生し、在庫がなくなる前に販売を完了する能力が著しく損なわれます。
平均的なユーザーよりも多くのリクエストを行い、最終的にキャプチャの後ろで立ち往生する、または
平均的なユーザー以上のリクエストは行わないため、平均的なユーザーよりも有利になることはありません。

サービスの低下や複雑さの増大に苦しむのは、虐待的なユーザーだけです。正当なユーザーは、がらくたの袋を買うのが簡単になったことを除いて、単一の変更に気付くことはありません.

補遺

未登録ユーザーのリクエストを、登録ユーザーよりはるかに低いレートで抑制します。そうすれば、ボットの所有者は、認証されたアカウントを介してボットを実行し、比較的制限的なスロットリングレートを回避する必要があります。

次に、本発明のボット作成者は、複数のユーザー ID を登録し、それらを使用して、希望するクエリレートを達成します。特定の期間に同じ IP から表示される ID を同じ ID と見なし、共有スロットリングの対象にすることで、これに対抗できます。

これにより、ボット作成者は、IP ごとに 1 つのボットと、ボットごとに登録済みの Woot アカウントを使用して、ボットのネットワークを実行する以外に手段がありません。残念ながら、これは、関連付けられていない多数の正当なユーザーと実質的に見分けがつきません。

この戦略を上記の戦略の 1 つ以上と組み合わせて使用することで、不正な使用パターンに従事していない登録ユーザーに最高のサービスを提供するという全体的な効果を生み出す一方で、登録済みおよび未登録の両方の他のユーザーに段階的にペナルティを課すことができます。、ステータス (匿名または登録済み) と、トラフィックメトリックによって決定される不正行為のレベルに応じて。

score 0 · Accepted Answer

2つのこと：

サーバー層ソリューション: mod_evasive (Apache を使用する場合)

http://www.zdziarski.com/projects/mod_evasive/

フロントレイヤーソリューション: 逆キャプチャ、またはその他の非侵入型キャプチャ

http://www.ccs.uottawa.ca/webmaster/reverse-captcha.html

score 0 · Accepted Answer

勝てないなら… ルールを変えろ！

スクリプト作成者が自分たちで作ったシステムよりも優れたシステムを提供してみませんか?
ボットスクリプトを使用していない人にとってより公平になるようにサイトを変更します。人々は登録 (CAPTCHA または電子メール認証) し、効果的に宝くじ大会に参加して当選します!

「勝つ」ことで、より楽しくなります。各人が少額の参加費を支払うので、勝者はさらに少ない金額で製品を手に入れることができます

score 0 · Accepted Answer

この目的のために、私は Cloudflare を使用します。これは、私のサイトには影響しませんが、悪意のあるユーザーを CAPTCHA で自動的にブロックし、より多くの機能を提供するためです。

score 0 · Accepted Answer

ターピット。ページビューを 1 秒あたり 1 回に制限しても、人間のユーザーは気になりません。
JavaScript によるリンク。単純なボットはそれを掘り下げません。ユーザビリティの時点で、統計によると、JS を使用していないユーザーは 1% 未満です。2a. 上記のハードコアバージョン。フラッシュ内のリンク。
パラメータは、クエリ文字列ではなくセッションに保存されます。ほとんどのボットはステートレスです。

score 0 · Accepted Answer

正直なところ、あなたの最善の解決策は、Woot-Off 中のアイテムをログインユーザーのみに表示し、各ログインユーザーが 500 ミリ秒ごとに 1 回のホームページ更新に制限することだと思います。(または、Woot-Off 中に認証されていないユーザーにアイテムの画像のみが表示されるようにし、Random Crap に常に同じ画像を使用しないようにすることもできます。) Woot ユーザーは、彼らがクリーミーなボウルを手に入れるのを助けるための手段としてそれを売ってください、そしてそれが彼らがより速くチェックアウトするのを助けることも指摘できます. キャプチャを使用する場合でも、それ以外のものはすべて、典型的な軍拡競争の対象となります。

score 0 · Accepted Answer

疑わしい IP をブロックする代わりに、1 分あたりのヒット数が増えるにつれてアドレスに与えるデータの量を減らすことが効果的かもしれません。そのため、ボットがランダムに変化する秘密のしきい値を超えてヒットした場合、データは表示されません. ログインしているユーザーには、常にデータが表示されます。サーバーに頻繁にアクセスするログインユーザーは、再認証を強制されるか、キャプチャが与えられます。

score 0 · Accepted Answer

ボットが理解できないように、ページの特定の部分を画像に変換します。

たとえば、0 ～ 9 の整数、ドル記号、および小数点の小さなイメージを作成します。ページの読み込み時にクライアントのコンピューターに画像をキャッシュし、サーバー側で実行されるコードを介して選択された画像を使用して価格を表示します。ほとんどの人間のユーザーは違いに気付かず、ボットはアイテムの価格を知りません.

score 0 · Accepted Answer

長年のWOOTerとしての私の意見

注文時に CAPTCHA をご利用いただければ幸いです。これは BOC に対してのみオンになっています。ほとんどのウーターは同意すると思います。しかも、99.9%の確率で注文画面にすらたどり着けず、すぐに売り切れてしまうので、ほとんど誰にもわかりません!!

CAPTCHA を本当に難しい数学の問題にしてくれれば、長年数学を勉強することの実際的なメリットを母に説明できるようになるでしょう。

score 0 · Accepted Answer

IP アドレスフィルタリングが法外に高価である理由がわかりません。IIS を使用すると、ネイティブコードでこれを行う ISAPI フィルタを作成できます。Apacheにも同様のインターフェースがあると確信しています。クライアントの IP アドレスを使用して、禁止リストやその他のナンセンスに依存しない HTTP リクエストの単純なレートリミッターを作成できます。

score 0 · Accepted Answer

これに対する簡単な解決策があるのではないかと思っています。

がらくたセールを示すメッセージがテキストで投稿され、これがスクレイパーが探しているちょっとした情報だと思います。

代わりに画像を使用してアナウンスを行うとどうなりますか? そうすることで、デザイン上の問題が発生する可能性がありますが、それらは克服され、独創的な創造性の原動力となる可能性があります。

問題 1
画像専用のデザインスペースが必要です。(本当にトリッキーになりたいですか? このスロットを介してローカル広告を回転させます。もちろん、スクレイパーに匂いを与えないように、画像の名前は静的である必要があります。これは、広告盲目について心配する必要のない 1 つのスロットです...)

問題＃2
RSS。誰もがフィードリーダーで画像を表示できるかどうかはわかりません。十分な数のユーザーができれば、画像で構成される毎日のフィード更新の送信を開始できます。ほとんどの日に必要な雑多なものを送信してから、必要に応じてがらくたセールのアラートに切り替えることができます.

わかりません... フィードアイテムが送信されるたびにボットがあなたのサイトにアクセスするようにプログラミングするでしょうか?

その他の問題？おそらくたくさん。ただし、これはブレインストーミングの助けになるかもしれません。

気をつけて、
ブライアン

score 0 · Accepted Answer

以下に、いくつかの有効な仮定を示します。

自動化されたソリューションは壊れる可能性があり、壊れるでしょう。
サイトを人間の入力 (例: CAPTCHA) を完全に必要とするようにすると、ログイン/チェックアウトなどが非常に難しくなります。
販売できるキャベツの弾帯の数には限りがあります。
クライアント側の Cookie を使用して、セッションごとにユーザーを追跡できます。
ここでは、非常に筋金入りの犯罪者を扱っているわけではありません。これらは、法律を曲げますが、違反するのではなく、単に技術的な人々です。ボット経由で注文が成功すると、その人の家に届きます。

解決策は技術的なものではありません。ポリシー的なものです。

すべてのクライアントセッション ID を Web サーバーに記録します。
「制限付きボット」ポリシーを制定します。たとえば、X 秒ごとに 1 つのスクリーンスクレイピングを行い、通常のブラウザを使用しているユーザーがリフレッシュできるようにします。この制限を超えていることが判明したユーザーは、勝ちません。
これに続いて、既知のボット所有者に大量の Leakfrogs を送信します。

score 0 · Accepted Answer

これが私がすることです：

がらくたの袋の販売のすべての入札者にサイトへの登録を要求します。
セールを開始したい場合は、メインページに「BOC セールがまもなく開始されます。メールを確認して、資格があるかどうかを確認してください」と投稿してください。
セール開始時に、その特定のセールに固有の URL を使用して、ランダムに選択された登録済みプレーヤーに招待状を送信します。
使用する URL が販売イベントごとに異なることを確認してください。
購入に使用したクレジットカード、PayPal アカウント、または配送先住所に基づいて、頻繁に当選する当選者の適格性を引き下げるために、ランダム選択招待アルゴリズムを微調整します。

メインページには保留中の BOC イベントのみが表示されるため、これはボットを阻止します。ボットは、電子メールで受信しないと URL にアクセスできず、受信できるという保証もまったくありません。

販売への影響が心配な場合は、販売ごとに 1 つまたは 2 つの BOC を配って、参加を奨励することもできます。所定の時間内にオファーが十分に受け入れられない場合は、追加の登録ユーザーに自動的にメールを送信し、各オファーの参加者プールを増やします。

ビオラ。大量のヒューリスティックや Web トラフィック分析を必要としない、公平な競争の場。システムは、膨大な数の電子メールアカウントを設定する人々によって依然として操作される可能性があります。

score 0 · Accepted Answer

オファーをリリースする時間を制限します。 たとえば、時間の開始から 7 分から 8 分後までに限定します。これを逸脱しないでください。リリース時刻の 30 分前に多くのチェックを行う IP には、数秒程度のペナルティを与えてください。ボットの所有者にとっては、1 時間ごとにスクレイピングをすべてではなく数分間だけスクリーンスクレイピングする方が有利になります。。時間。また、通常の人は 1 時間に 1 回サイトをチェックできますが、毎秒ではありません。そのため、通常の人はボットに対してより公平な立場に立つことができます。

Cookie: 一意の ID (データベーステーブルのキー) のみで構成される追跡 Cookie を使用します。Cookie がないクライアント、無効な Cookie、新しい IP から同じ Cookie を使用するクライアント、または高頻度で使用される Cookie に「解放の遅延」を与えます。

可能性のあるボットを特定する: Cookie により、ボットは制御する IP ごとに複数の Cookie を要求します。これは、追跡可能な動作です。発行された Cookie が 1 つだけの IP は、おそらく通常のクライアントです。多くの Cookie が発行された IP は、大規模な NAT 化されたネットワークまたはボットのいずれかです。それらをどのように区別するかはわかりませんが、企業はおそらく DNS サーバー、Web ページ、およびその性質のものを持っている可能性が高くなります。

score 0 · Accepted Answer

ASP.net AJAX コントロールツールキットのNoBot コントロールはどうですか?

ボットがユーザーの操作なしでサイトにアクセスするのを防ぐために、いくつかの自動化された JavaScript 要求とタイミングのトリックを行います。

申し訳ありませんが、これが要件を満たしていない場合は、
tl;dr >Dに電話する必要があります。

score 0 · Accepted Answer

フォーム名と ID をランダム化または暗号化し、フォームフィールドの順序をランダム化し、フォームラベルをランダムなキャプチャイメージにすると、スクリプト攻撃がより困難になります :-D

score 0 · Accepted Answer

血まみれのページ全体を CAPTCHA にしましょう!
セサミストリートのようなもの...これらのうちの8つは、ここに属していません...

9 個のアイテム、9 個の HTML フォーム、9 個の I WANT ONE ボタンを画面に配置します。
(9 は 1 日の数字にすぎません... レイアウトの見栄えを良くするために任意の数字を選択してください。おそらく 12 です。読み込み中のブラウザーの解像度に合わせてカスタマイズすることもできます...)

そして、一人一人のためにそれらをスクランブルします。
BOCがどれであるかを知るために「見られる」必要があることを確認してください...もちろん、これは、他の8つも「見られるだけ」である必要があることを意味し、それらが購入するアイテムではないことを認識します。
ページのソースの背後にあるすべてのものを参照するには、クレイジーなお尻の番号のみを使用してください。よし、BOT は BOC 時間を確認する... しかし、処理のために送信する適切な HTML フォームを選択するのは大雑把な推測です。

score 0 · Accepted Answer

最大数を超える数を検出した場合に IP アドレスをブラックリストに登録する単純な IP ファイアウォールルールを作成します。1 秒あたりのリクエスト数。

score 0 · Accepted Answer

サイトのスキャンを高価にします。

ボットをサイトから締め出すことができる方法はありません。私はあなたのためにサイトをスキャンする人間がいるサービスさえ知っています. それをどのように処理しますか？

ボットにとって最悪の事態は、サイトが変更されたときです。しばらくすると、ボットの実行を維持するのに費用がかかるか退屈になります。あなたのサイトには、新製品のように見えて実際にはそうではないアップデートがあるかもしれません。不定期に更新すると、予測できないことがボットにとって非常に難しくなります。

既知の IP である限り、IP を禁止することは対策になる可能性があります。犯罪者はプロキシを使用する必要があります。私が知っているプロキシはうまく機能しますが、速度が大幅に低下します。

score 0 · Accepted Answer

ボットユーザーにとって利益のないものにすると、ボットユーザーはすぐに消えてしまいます。

score 0 · Accepted Answer

あなたのサーバーはすでに着信リクエストのすべての IP をログに記録していると確信しています (ほとんどの場合)。そのため、データは既にそこにあります。

たぶんあなたなら：

ログで IP が特定のしきい値未満であることを確認して、「勝者」を検証するだけです (「grep | wc -l」を使用してカウントを取得します)。しきい値を超えている場合は、その IP を一時的にブロックします (1 時間程度?)。

「最後の」勝者と同じ配送先住所または支払い情報を持つ「勝者」、または「勝者」を広めるために特定の時間枠内に勝った「勝者」を失格にします。

ボットはそこまで理解できません。

スクレーパーのがらくたを困らせるには: 「ランダムながらくた」項目が上がったら、そのページの HMTL 出力を「コード難読化ツール」を介して実行します...ページの「表示」を変更しません...ランダムに生成された ID などでコードをスクランブルするだけです。

より陰湿な:

獲得した IP がログに表示される回数に基づいて、「獲得した」アイテムに請求される価格を引き上げます。ボットが勝っても、あなたも勝てます。:-)

score 0 · Accepted Answer

あなたはこの道を難しくしています。今日ボットサイトでサイトからBOCを獲得したばかりなので、おそらく自分を蹴るでしょうが、サイトのメインページのキャプチャにRANDOM CRAPテキストを入れるだけです. ボットはすべて、「RANDOM CRAP」というテキストを探します。したがって、基本的には、そもそもそれらをトリガーすることを避けるだけです. 目で見れば誰でも、「Random Crap」と書かれていることがわかります。

score 0 · Accepted Answer

手順:

(別の投稿者と gif スパマーからのアイデアを組み合わせる)

オファーページ全体を画像、広告コピーなどで表示します。
URL の価格を暗号化します。

攻撃:

ボットが URL にアクセスして、チェックアウトページの価格を表示する
- チェックアウトの値札を画像に変換する、または
- ユーザーが注文ページに移動する前にキャプチャを適用します。
帯域幅を食いつぶす
- 画像を使用して特別オファーを提供し、 HTML を使用して通常のオファーを提供します。
無謀なボットの注文
- 特別な「イメージ」オファーの一部は、実際には通常価格です。
RSS スクレイピング
- RSS フィードは、ハッシュキャッシュまたはキャプチャで支払う必要があります。
- これは、リクエストごとに行う必要があります。
- たとえば、ユーザーは 200 回の RSS ルックアップに対して 20 個のキャプチャを入力できます。
- DDOS の脅威が軽減されたら、オファーの電子メール通知を実装できます。

score 0 · Accepted Answer

おそらく IP ベースのボットを特定する方法を考えてみてはどうでしょうか。ただし、サイトへのアクセスをブロックせず、実際には何も購入できないようにします。つまり、ボットは利用規約に違反しているため、購入しても実際には入手できません。

score 0 · Accepted Answer

あなたの最終目標は、商品を購入できるより大きなユーザーベースに広がることです。

w00t のバッグをすべて同時に任意の IP アドレスにリリースするのではなく、1 ～ 2 時間にわたって IP アドレスの範囲にわたってリリースするようなことをしたらどうなるでしょうか。

255 袋の w00t があるとします。1.0.0.0 は最初の 1 分で購入でき、2.0.0.0 は 2 番目の分で購入できます (2 袋の w00t が利用可能になる可能性があります)、など。

次に、255 分後、w00t のバッグが 255 個すべて残っているわけではありませんが、すべての人が w00t のバッグを利用できるようにしました。

これにより、真の攻撃は 255 台以上のコンピューターを持つユーザーに制限されますが、ボットユーザーは自分の IP 範囲に割り当てられた w00t のバッグを「所有」できる可能性があります。

バッグを IP に公平に一致させる必要はありません (そして、何らかのタイプの MD5 / ランダムシードのものを使用する必要があります)... w00t の 10 バッグを段階的に配布する場合は、それが確実に配布されるようにする必要があります ~人口全体で均等に〜。

IPが悪い場合は、Cookieを使用して、Cookieを使用していないユーザーにw00tのバッグが提供されるユースケースを除外できます.

特定の IP、Cookie、またはアドレス範囲に極端な量のトラフィックがあることに気付いた場合は、w00t のバッグをそれらに比例して後で/最後に利用できるようにして、時々/安定した/遅い訪問者に、大量/迅速/可能性の高い訪問者の前に機会を与えます。ボットユーザー。

-- ロバート

score 0 · Accepted Answer

この回答が既に送信されている場合はご容赦ください。それらすべてを読んで理解しようとする答えはたくさんあります。

たまに購入 API を変更できなかったのはなぜですか? それは人間のユーザーには完全に透過的であり、ほとんどのボット購入者を殺してしまうのではないでしょうか?

実装の 1 つは、「I Want One」ボタンを押した後に、ユーザーが入力してページに送信する必要があるフィールドの名前を変更することです。実際に BOC を販売するのは年に何回ですか? それほど頻繁ではありません。したがって、BOC が販売されるたびに、異なる購入 API をプログラムしてテストし、すぐに使用できるようにすることは、大きなプログラミングの負担にはなりません。

古い不適切な API を使用しているボットがサーバーをダウンさせないように注意してください。毎回異なるサーバーで BOC 購入 API をホストすることもあるでしょう。そうすれば、ボットは、私たち人間の BOC 購入者が実際に使用していないサーバーをダウンさせることができます。

score 0 · Accepted Answer

感想（他は全部チェックしてないので小説かどうかはわかりません）

スワーミングへの対処:

毎日のトップページの内容をフラッシュ/フレックスオブジェクトに変換します。
- はい、不平を言う人もいますが、ここでは理想ではなく、一般的なケースを探しています.
- また、Flash オブジェクトの名前をランダム化して、予測可能な名前のパターンにならないようにする必要があります。
Akamai または別の CDN を使用して、このフラッシュオブジェクトを事前に外部に展開します。Akamai はランダムな URL のように見えるものを生成するため、予測が困難です。
新しい販売の時期になったら、ローカルで URL を変更して Akamai の適切なオブジェクトを参照するだけで、人々はそこからフラッシュオブジェクトを取得して、その取引が BoC であるかどうかを確認します。

一日の終わり - Akamai が真夜中の大量のトラフィックを処理します

自動購入への対応

作成した各フラッシュオブジェクトには、画像、リンク、任意の ID など、非常に多くのコンテンツが隠されている可能性があります。フラッシュも難読化できるはずです。
フラッシュオブジェクトが「ライブになる」と、人々はそれを攻撃し始めます。しかし、偽陽性が非常に多いため、単純な文字列スキャンは役に立ちません。フラッシュをローカルで実行することをシミュレートする必要があります。
しかし、フラッシュはテキストを書きません。線と形を描きます。さまざまな色の図形はすべてタイマーに接続されており、さまざまな時間に表示および非表示になります。
- Colbert Report を見たことがあれば、イントロに Colbert を説明する何百もの単語が含まれていることをご存知でしょう。イントロにそのようなものを想像してみてください。これには常に Bag O Crap が含まれます。
- ここで、イントロに任意の時間がかかることを想像してみてください - 時には数秒、時には1分以上かかることもあります（おかしくしてください）
- その間、"Bag O Crap" はコンスタントに登場しますが、これも明らかにイントロの一部です。
- 最後に、その日の実際の取引が明らかになり、アクティブな「きらめき」効果により、キャンバスの単一のスナップショットでは実際の製品名を明らかにすることが困難になります. これは、アニメーションの背景の上に浮かんでいて、まだ「bag O crap」と表示され、常に動いています。
- 繰り返しますが、これらはすべてテキスト文字列ではなく、線と形状で処理されます

最終結果 - ハッカーは取引の画像スナップショットを大量に撮り、すべての誤検知を分離して実際の取引を特定する方法を見つけ出すことを余儀なくされます。その間、人間はそれをただ見ているだけで、目の疲れとテキストのギャップを埋める能力の間で、取引をそのまま読むことができます.

これは永久に機能するわけではありませんが、しばらくは機能します。

もう 1 つのアイデアは、以前にそのアカウントで何かを購入したことがない限り、人々が BoC を購入することを単純に制限し、二度と BoC を購入できないようにすることです。

score 0 · Accepted Answer

ボットを対等な場所で競争させるだけです。タイムスタンプを暗号化し、非表示のフォームフィールドに貼り付けます。提出物を受け取ったら、それを解読して、経過した時間を確認します。人間のタイピング能力の限界を超える場合は拒否します。現在、ボットと人間は、同じ速度でゴミ袋を買おうとすることしかできません。

score 0 · Accepted Answer

これから説明する方法には 2 つの要件があります。1) Javascript が適用されている 2) 有効なhttp://msdn.microsoft.com/en-us/library/bb894287.aspxブラウザーセッションを備えた Web ブラウザー。

これらのいずれかがないと、「設計上」運が悪くなります。インターネットは、匿名のクライアントがコンテンツを表示できるように設計されています。単純な HTML ではこれを回避する方法はありません。ああ、単純な画像ベースの CAPTCHA は簡単に打ち負かすことができると言いたかっただけです。作成者も認めています。

問題と解決策に沿って移動します。問題は 2 つの部分にあります。1つ目は、「悪いことをしている」という理由で個人をブロックできないことです。これを修正するには、ブラウザの有効なセッションを取り込んで md5sum + salt + ハッシュ (自分のプライベートデバイスの) を生成し、それをブラウザに送り返すメソッドをセットアップします。ブラウザは、投稿/取得のたびにハッシュ化されたキーを返す必要があります。有効なブラウザセッションが得られない場合は、「有効な Web ブラウザを使用してください」と返信します。一般的なブラウザーはすべて、有効なブラウザーセッション ID を持っています。

少なくともそのブラウザセッションの ID を取得したので (永久にロックアウトされないことはわかっていますが、単純なスクリプトを使用してブラウザセッションを「更新」することは非常に困難です)、セッションを効果的にロックアウトできます (つまり、スクリプターが実際にあなたのサイトにアクセスするのは厄介なことであり、有効なユーザーにペナルティはありません)。

この次の部分は、javascript が必要な理由です。クライアントでは、キーボードからの各文字とテキストエリア内のテキストの値に対して単純なハッシュを作成します。その有効なキーは単純なハッシュとしてサーバーに渡され、検証する必要があります。この方法は簡単にリバースエンジニアリングできますが、個人がデータを送信する前に通過しなければならない 1 つの余分なフープになります。これはデータの自動投稿を防ぐだけであり、Web サイトへの絶え間ない訪問による DOS を防ぐことはできません。ajaxにアクセスできる場合でも、ソルトとハッシュキーをネットワーク経由で送信し、JavaScriptを使用してネットワーク経由で送信されるonkeypress文字「有効なトークン」を構築する方法があります。はい、私が言ったように、簡単にリバースエンジニアリングできますが、うまくいけば、私がどこに向かっているのかがわかります。

トラフィックを介した絶え間ない悪用を防ぐために。有効なセッション ID が与えられると、パターンを確立する方法があります。これらのパターンは (リクエスト時間をオフセットするために Random が使用されている場合でも)、人間が同じエラーマージンを再現しようとした場合よりもイプシロンが低くなります。セッション ID があり、「ボットのように見える」パターンがあるため、200000 バイトではなく 20 バイトの単純な軽量応答でそのセッションをブロックできます。

ここでわかるように、目標は、1) 匿名を非匿名にすること (たとえそれがセッションごとであっても)、および 2) ボットがシステムを使用する方法でパターンを確立することによって、ボットと通常の人を識別する方法を開発することです。後者は不可能だとは言えません。以前にやったことがあるからです。私の実装はビデオゲームのボットを追跡するためのものでしたが、ボットとユーザーを識別するアルゴリズムは、Web サイトへのアクセスの形に一般化できると思います。ボットが消費するトラフィックを減らすと、システムの負荷が軽減されます。これでも DOS 攻撃を防ぐことはできませんが、ボットがシステムに与える負担を軽減することはできます。

score 0 · Accepted Answer

おそらく、ボットがくだらないセールと他のすべてのコンテンツを区別することを完全に不可能にするソリューションが必要になるでしょう。

これは一種のキャプチャテーマのバリエーションですが、ユーザーがキャプチャを解決して自分自身を認証する代わりに、キャプチャは販売の説明であり、視覚的に楽しい (ただし、背景によって多少不明瞭になる) 方法でレンダリングされます。

score 0 · Accepted Answer

ブラウザでネイティブに実行されないフロントページコンポーネントとショッピングカートを開発します。Flex/Flash や Silverlight などを使用すると、スクレイピングがはるかに難しくなり、サーバー通信を完全に制御できるため、コンテンツをスクリプターから完全に保護できます。

score 0 · Accepted Answer

より良いボットを構築する

市場はあなたに何かを伝えています。彼らはそのバッグを手に入れたいと思っています。したがって、スクリプトと戦うのではなく (RIAA v ファイル共有誰か?)、より優れたボットを構築します。

スクリプトの子供が組み立てることができるものと同じかそれ以上のインストール済みアプリをすべての人に提供します。ユーザーはブランド化されたアプリをインストールし、がらくたの袋が提供されるたびに。アプリは自動的に購入を試みます。現在の BOC を逃した場合、アプリには次の BOC 販売のチャンスを与える「チケット」があります。そのため、ユーザーが独自のスクリプトを実行しても、次の boc セールの「チケット」を手に入れることはできませんが、公式アプリのユーザーは手に入れることができます。

boc の販売の間に、アプリは販売中の現在のアイテムを表示できます。地獄、ユーザーが woot アプリに「メモリースティック」を探すように指示できるようにします

公式の woot bo-c+ スクリプトアプリが優れているか劣っている場合、誰が独自のスクリプトを作成しますか?

さらに、woot は別の方法で顧客とつながることができます。

あなたの顧客は、彼らが何を望んでいるのかをあなたに話しています。

score 0 · Accepted Answer

シスコの CAPTCHA プログラムの料金を支払うのに十分な額を、今日の照明で稼ぐことができます!! 私たちは皆、コンサートのチケットやその他のものを購入することに慣れています.. それは公正に思えます. 今日行われている方法は、一部の人を動揺させ、宝くじや懸賞について疑問を投げかけています. 試してみる前に確認したと思いますが、BOCを購入するのは本当に楽しい方法ではありません...それはすべての興奮を取り除きます!

BOC を最初に獲得したり、目の前にいても優れた製品を手に入れたりすると、人々は Woot に引き寄せられます。ランダムな BOC が表示されるのを待っている間に、必要のないものをぶらぶらして購入する理由がなければ、売上は減少します。CAPTCHA は、これらの人々を打ち負かし、Woot の興奮を維持する唯一の方法かもしれません。

私は前回 BOC を注文した最初の 1 人で、最初の注文は 100 万ドルの送料で破棄され、2 番目の注文は完了しましたが、後でアカウントから削除されました。私は動揺していた。私は Woot を離れましたが、他の日に行ったようにアイテムを購入していません。今日、この方法でもう一度試してみました。私は、楽しいもののためにCAPTCHAなしで将来そうなるとは思わない.

Woot のようになろうとしているサイトはたくさんあります。もちろん、彼らはあなたのレベルに達していません。商品説明を読んでいるのは、商品が欲しいからではなく、笑いのためにチェックインすることです。誰かがより公平なプログラムを持ち込んで、あなたのビジネスのほとんどを奪ってしまうのを見たくありません。

私の意見です。私は看護師なので、ボットやコンピューターについてはほとんど何も知りません..しかし、私の投票は、より高いレベルにアップグレードすることです...それはあるべきです:)ロリ

score 0 · Accepted Answer

これに対する解決策は、ログインと購入のアクションにクライアント側の処理を少し追加することです。個人が影響を受けないように、処理は無視できる量である可能性がありますが、ボットがタスクを何度も実行しようとすると、余分な作業負荷によって妨げられます。

処理は、サイトで JavaScript を要求する必要がない場合を除き、JavaScript で実行される単純な方程式で解決できます。

score 0 · Accepted Answer

うーん、「Linux Firewalls」Attack Detection and Response with ... を読んだことを覚えています。そして、他の誰かもそれを示唆しています。クライアントを一時的にブロックするか、段階的な手順でブロックして、クライアントを抑制します。いくつかのサイトからのリアルな場合、これは非常に効率的でなければなりません

よろしく

score 0 · Accepted Answer

サーバー上のiptables（Linuxベースの場合）を介してIPアドレスごとに制限する同時接続を使用するか、専用の「ルーター」を使用します

score 0 · Accepted Answer

JavaScript を使用して、情報を動的にページに書き込みます。JS レンダリングエンジンがなければ、スクリーンスクレイパーやボットは情報を読み取ることができません。

score 0 · Accepted Answer

私の理解が正しければ、あなたの最大の問題は、自動購入自体ではなく、画面のスクレイピングにあります.

もしそうなら、あなたの最も効果的なステップは、ページをランダムにエンコードしてスクリーンスクレイピングを無効にすることです。(16 進コード、Java エンコーディング、画像を使用し、周囲のコード構造を変更します...)

そうなると、彼らはスクレイピングコードを絶えず書き直す必要があり、その結果、彼らがあなたの「がらくた」を自動的に購入するコストがはるかに高くなります。彼らが管理できる場合。彼らはおそらく、あなたのウェブサイトから何も得られないことに気づき、それをやめるまで、しばらくあなたのウェブサイトにアクセスし続けるでしょう.

ボットを完全に混乱させることの欠点は、検索エンジンのクローラーを完全に混乱させることです。

score 0 · Accepted Answer

ボットとして特定したユーザーのクレジットカードをブロックしないのはなぜですか?

あなたのウェブサイトでボットの使用が違法であることを公表する
ボットを識別する特定のヒューリスティックを見つけます (これは、たとえば、短期間の IP 追跡によって、またはボットがフォームを感じるのにかかる時間によって行うことができます)
ボットとしてタグ付けした誰かがアイテムを購入した場合、将来の使用のために彼のクレジットカードをブロックします
次に彼が購入しようとしたときは、それを許可せず、商品を在庫に戻します

プロでもいずれはクレジットカードを使い果たしてしまうと思います。

ボットがあきらめると、サーバーの負荷は時間とともに減少するはずです。もう 1 つのアイデアは、ページをサーバー間で分離することです。たとえば、RSS フィードをあるサーバーに、ホームページを別のサーバーに、チェックアウトを別のサーバーに配置します。

幸運を。

score 0 · Accepted Answer

pubsubhubbub を使用して RSS フィードを公開した場合、ユーザーは Woot-off の次のコンテンツを表示するために Web ページに何度もアクセスする必要はありません。Google に表示されるのを待つだけです。読者。

score 0 · Accepted Answer

かなり単純な解決策は、フォームのレンダリングと応答の取得の間の時間差を追跡することです。通常、ボットの応答時間はミリ秒と非常に短く、ユーザーはそれを行うことができません。または数時間の極端に長い応答時間。

より詳細な説明とともに、それを行うdjangoスニペットがあります：

Captcha の代替 (人間の操作なし)

score 0 · Accepted Answer

BradC の回答(Ned Batchelder の記事の提案を使用) は気に入っていますが、別のレベルを追加したいと考えています。フィールド名だけでなく、フィールドの位置とそれらを非表示にするコードもランダム化できる場合があります。

さて、この最後の部分は難しい部分であり、正確な方法はわかりませんが、JavaScript と CSS の経験が豊富な人なら理解できるかもしれません。もちろん、常に同じ位置を維持することはできません。なぜなら、スクリプターは位置 (x,y) を持つ要素が実際の要素であると判断するからです。フォーム要素をページから移動したり、互いに重ねたりするために、フォーム要素の位置を他の要素に対して変更するコードが必要になります。次に、これを行うコードを難読化します。いくつかのランダム性が導入されています。新しいアイテムが利用可能になる前に、難読化を毎日自動的に変更します。適切な CSS と JavaScript の実装 (および人間がページのレイアウトを読み取るためのコード) がなければ、ボットはどの要素がユーザーに表示されているかを理解できないという考えです。もちろん、サーバー側のコードは、どのフィールドが本物で、どのフィールドが偽物かを認識しています。

要約すれば：

フィールド名はランダムです
フィールドの順番はランダム
フィールド非表示コードが複雑
フィールド隠蔽コードは難読化されています - ランダムに
乱数は、サーバー側のコードによって毎日自動的に変更されます

あなたが与えた制約では、ある種の「軍拡競争」を回避する方法はないと思いますが、それはすべてが失われるという意味ではありません. 軍拡競争の側を自動化でき、スクリプターが自動化できない場合は、毎回勝つことができます。

score 0 · Accepted Answer

BOC を最も頻繁に購入したユーザーの記録が必要です。それらのアカウントなどを禁止するだけではどうですか。確かに正当なユーザーはこのプロセスで禁止されますが、あなたは製品を提供するビジネスであり、ユーザーのグループによって虐待されている場合など、彼らへのサービスを拒否する権利があります. Paypal や銀行口座など、ユーザーに関する多くの情報を持っているため、これらのアカウントを禁止して、ボットユーザーに新しいアカウントの取得を強制することができます。確かに、BOC を常に購入したり、ネットからダウンロードしたりするためのスクリプトを考え出すことはできますが、それよりもモラルが高いです。実際に BOC の購入に成功したことはありませんが、多くのことを期待して BOC を受け取りたい正当なユーザーのフラストレーションを知っています。おそらく、時々 BOC を個別のアイテムとして提供する代わりに、毎日ランダムなユーザーにそれを与えることができます。アイテムを受け取ると、小さなメモと、BOC も受け取ったことを示す追加のアイテムが表示されます。その場合、誰かが BOC を取得できる唯一の方法は、実際の人間だけが欲しがるであろうものを合法的に購入した場合です。コーヒーメーカーか何かを購入し、正当な購入に加えて 42 インチテレビか何かを受け取ることほど良いことはありません。スクリプトキディーの大半は、BOC を取得するためにあなたのサイトに関心を持たなくなると思います。また、10 ドル以上の購入を約束する必要があります。その場合、誰かが BOC を取得できる唯一の方法は、実際の人間だけが欲しがるであろうものを合法的に購入した場合です。コーヒーメーカーか何かを購入し、正当な購入に加えて 42 インチテレビか何かを受け取ることほど良いことはありません。スクリプトキディーの大半は、BOC を取得するためにあなたのサイトに関心を持たなくなると思います。また、10 ドル以上の購入を約束する必要があります。その場合、誰かが BOC を取得できる唯一の方法は、実際の人間だけが欲しがるであろうものを合法的に購入した場合です。コーヒーメーカーか何かを購入し、正当な購入に加えて 42 インチテレビか何かを受け取ることほど良いことはありません。スクリプトキディーの大半は、BOC を取得するためにあなたのサイトに関心を持たなくなると思います。また、10 ドル以上の購入を約束する必要があります。

score 0 · Accepted Answer

あなたの最善の策は、IP が入ってくるのを監視することだと思いますが、あなたが言及した問題をいくつかの方法で軽減することです。最初に、確率的ハッシュ (ブルームフィルターなど) を使用して、以前に確認された IP をマークします。このクラスのアルゴリズムは非常に高速で、完全に大規模なセットサイズに対応できます。次に、段階的な応答を使用します。これにより、サーバーの遅延が各要求に追加され、「最近」IP をどれだけ見たかによって予測されます。

score 0 · Accepted Answer

IP または一連の他のメカニズムを介してボットを識別します。
ボットとして識別されたものには、常に通常のフロントページを提供します。

ボットであると誤って識別された実在の人物はスペシャルを取得しませんが、とにかく気付かないでしょう.

ボットの所有者は、あなたがボットを特定したことに気付かないため、スクリプトの適応を停止します。

score 0 · Accepted Answer

私は Web 開発者ではないので、これを少しだけ理解してください。ただし、ここに私の提案があります。

各ユーザーは、現在のがらくたセールを見るかどうかを判断する Cookie (ランダムなデータの文字列を含む) を持っています。

(Cookie を持っていない場合、それらは表示されません。したがって、Cookie を有効にしないユーザーは、くだらない販売を表示することはありません。また、新しいユーザーが最初にページを表示したときに表示されることはありませんが、その後表示されます) .

ユーザーが Web サイトを更新するたびに、ユーザーは現在の Cookie をサーバーに渡します。サーバーはそれを使用して、新しい Cookie を与えるか、現在の Cookie をそのままにしておくかを決定します。それに基づいて、がらくたセールの有無にかかわらずページを表示するかどうかを決定します。

サーバー側で物事をシンプルに保つために、任意の時点で言うことができます。また、「過去 2 秒間に生成された」とラベル付けされた Cookie が他にもいくつかありますが、これらは常に変更されません。したがって、それよりも速くページを更新すると、新しいページを取得できません。

(...ああ、ボットが古い Cookie を復元してユーザーに返すのを止めることはできないと思います。それでも、ここのどこかに解決策があるかもしれません。)

score 0 · Accepted Answer

すべてのボットを停止することは、特に CAPTCHA を使用しないと非常に困難です。スクリプターの生活を苦しめるために、さまざまな対策を講じるという観点からアプローチする必要があると思います。

これは、それらのいくつかを取り除くための1つの手段であると私は信じています:

各応答でタグの ID とクラス名をランダム化してみることができます。これにより、ボットは重要なタグの位置とコンテキストに依存せざるを得なくなり、より洗練されたボットが必要になります。さらに、CSS で相対または絶対配置を使用する場合は、タグの位置をランダム化できます。

このアプローチの最大の欠点は、ランダム化された ID とクラス名を含める必要があるため、CSS ファイルがクライアント側でキャッシュされないようにするための措置を講じる必要があることです。これを克服する 1 つの方法は、外部の CSS ファイルを使用せず、代わりにランダム化されたセレクターを含む CSS を<head></head>ページのセクションに配置することです。これにより、ランダム化された CSS をページの残りの部分と共にクライアント側でキャッシュできます。

score -1 · Accepted Answer

複数（4つ以上）の注文ボタンを使ってみてはいかがでしょうか。ファイル名image1はimage4.

販売ごとに、#各オプションの画像をランダムに割り当てます。ユーザーが誤って間違ったものをクリックしないように、かなり大きくします。画像は同じファイルサイズになります。
IP がボタンをクリックすると、適切な Web ページ (注文プロセス、または「おっと、間違ったボタンをクリックしました」) に移動し、サーバーへの再アクセスから 2 分間のタイムアウトが与えられます。

score -1 · Accepted Answer

（おそらく）リストされていない解決策があります（ここにあるすべてのものをまだ読んでいないため...）

ブラウザーのユーザーエージェント文字列を使用して、一意のユーザーを追跡できます。基本的に、どの情報が「一意」に利用できるかを確認することで、(同じ IP アドレスであっても) 異なる人々を区別するのに十分な情報を取得できます。

EFFによって書かれたこの記事とこのサイト(これも EFF) をチェックしてください。このサイトでUser Agentは、ブラウザからのあなたに基づいてあなたのユニークを「テスト」します。

一意性をさらに高めるには、一意性と IP アドレスからの情報のビットを比較して、実際に犯罪者/ボットまで可能性を突き止めることができます。

EFFのこのpdfもチェックアウトしてください

score -1 · Accepted Answer

やるべきことは、スパマーにとっての利益を上回る努力をすることだけだと思います。これは「ブレインストーミング」のアイデアであり、これがどのように実装されるかについての技術的な詳細をすべて知っているわけではありません。いくつかの調査を行う必要がありますが、現在の知識から、他の提案されたアプローチが拒否された場合は調査する価値があります.

サイトですでにフラッシュを使用しているので、フラッシュコントロールを使用してフォームの送信を支援したり、送信したりしないのはなぜですか? コントロールは、キーペアまたは値をハッシュする他のアルゴリズムを使用して、Web サーバーと暗号化された通信を行うことができますか?

フォーム全体がフラッシュになる可能性があると思いますか？個人的には Java アプレットを使用します。これが私のお気に入りの言語だからです。

score -1 · Accepted Answer

スクリプトを使用しない人間にアイテムを販売します。
「通常の」ユーザーが人間であることを証明するために完了するタスクを実行するのに煩わされないでください。

したがって、基本的には、特定のユーザーが個人であるかどうかを、証明させずに調べたいと考えています。私が知る限り、それはインターネット上では不可能です。申し訳ありません。

メカニズムをオークションに変更することをお勧めします。

score -1 · Accepted Answer

必ずしも質問のタイトルではなく、目標に対する可能な解決策：

すべての人に特別な取引を提供する代わりに、一度にランダムな IP アドレスのセットに提供します。たとえば、IP 空間を 256 の一意のブロックに分割し、時間 = 0 で最初のブロックに IP アドレスを持つ人のみを許可し、時間 = 5 秒で最初のブロックと 2 番目のブロックの人々を許可します... まで最後のタイムスロットが到着し、全員が取引を確認できるようにします。それをランダム化する 1 つのアイデアは、IP の md5/sha の最下位ビットと、取引に基づくソルトを取得することです。

これにより、スクリプターは、応答時間がほぼゼロであるという事実と、複数の IP アドレスを持つことによる強みという点で引き続き有利になりますが、特定のボットが、他の顧客よりも有利になることはありません。彼らのIPアドレスのために彼らよりも「幸運」です。

これを他のいくつかのアイデアと組み合わせると、良いアイデアのように思えます。

score -2 · Accepted Answer

これは常に難しい問題です。CAPTCHA の使用を避けたいというあなたの希望に拍手を送ります。HTTP リクエストを介して確認できる動作に基づいて、最初にブロックすることをお勧めします。bad behaviorとして知られるツールを見てください。私がいくつかのサイトで使用してきた年に、実際の人間をまだブロックしていません。ほとんどのボットは、Web ブラウザーのふりをするのがうまくいきません。プロジェクトハニーポット API の使用もお勧めします。

次に、ラベルを含め、フォームをランダムに変更します。これはボットを騙すためのものではなく、ボットの IP アドレスやプロキシを発見できるようにするためのものです。エントリを xx 回台無しにするものは、そのリストに追加する必要があります。

最後に、何らかの人間による検証プロセスを使用する必要がある場合は、次のようなことを試してください。

[ image of a pig ]

The image above is a: [ ] dog  [ ] house [ ] pig

それは人間にとってそれほど迷惑ではありません。

つまり、問題に対する「1 つの」解決策はありません。100% 成功するとは期待しないでください。煩わしさを非常に鈍い轟音に減らすという目標を設定すると、かなり早くそれを行うことができるはずです.

scripting - スクリプターがあなたのウェブサイトを非難するのを止める

状況

評価

元の質問

目標

129 に答える 129

まず、単純なボットを取り除きます

次に、サーバーを非常に高速にします。

結論

手順:

攻撃:

より良いボットを構築する

Related

Reference