統計 Web サービスのコーディングに戻ると、画像とグラフを動的に生成する必要がありました。生成される画像は、リクエスト パラメータ、データ リポジトリの状態、および一部のヘッダー情報によって異なります。
したがって、もし私があなたなら、画像を提供するための REST Web サービスを作成します。それほど難しくありません。特定のIPアドレスが気に入らない場合は、データリクエストの画像ではなく、舌を出した漫画（または爆弾を受けながら踊るOBLサンバのアニメーションGIF）を表示できるため、かなりくすぐったいです.
あなたの場合、http ヘッダーでリファラー (またはリファラー) を確認しますよね? httpヘッダーのリファラーフィールドを隠したり、空白にしたり、偽造したりすることができるので、私は疑わしいです。
そこで、リファラーフィールドをチェックするだけでなく、値が変化するデータフィールドを作成します。値は、単純な値の一致である可能性があります。
第二次世界大戦中、ルーズベルトとチャーチルは暗号化を使用して通信しました。それぞれが同じディスクのスタックを持っていましたが、これには暗号化メカニズムが何らかの形で含まれていました。それぞれの会話の後、2 人ともディスクを破棄し (そして再利用することはありませんでした)、次回の会話時にスタック上の次のディスクに到達できるようにします。
ディスクのスタックの代わりに、イメージ コンシューマーとイメージ プロバイダーは同じ 32 ビット トークンのスタックを保持します。32 ビットでは、10 分間で最大 40 億の期間が得られます。スタックはランダムに並べられます。「ランダム ジェネレーター」は真のランダムではなく、十分に長いシーケンスが提供された場合に予測できる方法で実際にアルゴリズム化されていることはよく知られているため、「真のランダム ジェネレーター」を使用するか、毎週スタックを再シーケンスする必要があります。
待ち時間の問題により、プロバイダーは現在の期間、最後の期間、および次の期間からのトークンを受け入れます。ここで、期間 = セクター。
ブラウザ上の ajax クライアント (おそらく gwt) は、サーバーから 10 分ごとに更新されたトークンを取得します。ajax クライアントは、そのトークンを使用して画像を要求します。イメージ プロバイダー サービスは古いトークンを拒否し、ajax クライアントはサーバーから新しいトークンを要求する必要があります。
これは防火方法ではありませんが、飛散防止であるため、スパムリクエストの数を減らす/思いとどまらせることができます (ほぼゼロになると思います)。
「真にランダムな」シーケンスを生成する方法は、やはり手早く汚いものです。さらに、シーケンスの値を手動で並べ替えたり削除したりして、数分モンキーレンチを手動で投入することにより、アルゴリズムで生成された「ランダムな」シーケンスに取り組みます。それは、アルゴリズムの予測可能性を台無しにします。おそらく、モンキーレンチスロワーを書くことができます。しかし、アルゴリズム モンキー レンチ ストライカーは、予測可能なアルゴリズムを別の予測可能なアルゴリズムの上に追加するだけで、全体的な予測可能性をまったく低下させません。
巡回冗長マッチングを迅速で汚い「暗号化された」トークンマッチングメカニズムとして採用することで、状況をさらに強迫的に制限することができます。
等間隔の 8 つのセクターに分割された円があるとします。8 セクターすべての誰にでもアドレス指定できるようにするには、3 桁の 2 進数が必要です。各セクターがさらに 8 つのサブセクターに分割されていると想像してください。これにより、各サブセクターを追加の 3 バイトでアドレス指定できるようになり、合計 6 バイトになります。
10 分ごとに一致する値を変更する予定です。イメージ プロバイダーと承認されたすべてのコンシューマーは、セクター アドレスの同じスタックを持ちます。10 分ごとにセクター アドレスを破棄し、次のセクター アドレスを使用します。コンシューマーがプロバイダーに一致する値を送信する場合、セクター アドレスではなくサブセクター アドレスが送信されます。そのため、プロバイダーが現在受け入れられているセクターに属するサブセクター アドレスを受け取る限り、プロバイダー サービスは正しいイメージで応答します。
ただし、サブセクター アドレスは、難読化シーケンス アルゴリズムによって再マップされます。同じセクタ内の各サブセクタ アドレスがまったく似ないようにします。このように、すべてのブラウザーが同じトークン値または非常に類似したトークン値を受け取るわけではありません。
16 ビットのセクター アドレスがあり、各セクターには 16 ビットのサブセクター アドレスがあり、32 ビットのトークンを構成しているとします。つまり、同じトークン セクターを運ぶ 65536 の同時ブラウザー クライアントを使用する余裕がありますが、2 つのトークンが同じ低い予測可能性の値を持つことはありません。すべてのセッション ID にトークン サブセクター値を割り当てることができるようにします。イメージ プロバイダー サービスに対して 65536 を超える同時セッションがない限り、2 つのセッション ID が同じサブセクター トークン アドレスを共有する必要はありません。そうすれば、スパマーがセッション ID を偽造する機器/施設にアクセスできない限り、サービス拒否攻撃以外にイメージ プロバイダーがスパミングされることはありません。
予測可能性が低いということは、スヌーパーやのぞき見をする人が許容できるトークンを作成して画像プロバイダー サービスにスパムを送信する可能性が低いことを意味します。
確かに、通常のボットは成功することができません - ANNONYMOUS グループを本当に怒らせ、彼らが純粋な楽しみからあなたのサーバーにスパムを送信することに決めた場合を除きます。それでも、モンキー レンチをセクター アドレス スタックとサブセクター マップに投入したとしても、次のトークンを予測することは非常に困難です。
ところで、Cyclic Redundancy マッチングは実際にはエラー訂正技術であり、暗号化技術ではありません。