クライアント認証でDDoSまたはスパムフォームの送信を防ぐことはできますか？

Question

私のWebアプリには公開クエリフォームがあり、アーキテクチャチームはOAuth2を使用してWebアプリを認証するように求めていますこれと同様ですが、役に立たないと思います。

保護する最善の方法はreCAPTCHAによるものだと思います。

クライアント認証を使用して、DDoSまたはスパムフォームの送信を防止できますか？

Conor Mancone · Accepted Answer

tl/dr：ブラウザーベースのボットは自動的に認証され、ブラウザーなしのボットははるかに簡単に停止されるため、ブラウザーでのクライアント認証は役に立ちませんとにかくメソッド。「クライアント認証」はブラウザに対して実際には効果的ではないため（そして他の「種類のクライアント」に対してはわずかに効果的です）、これは実際には驚きではありません。残念ながら、Captchaは唯一の現実的なソリューションですが、標的型攻撃から保護することはできません。

バックグラウンド

コメントから詳細を明らかにしたい。私の理解は、ここでの目標は、フォームを使用するために誰かにログインを要求することではないということです。むしろ、クライアント（この場合は、ユーザーのブラウザーで実行される、作成したJavaScriptアプリ）がサーバーで認証されるようにして、Webサイトを閲覧している人だけがフォームを送信できるようにします。この認証は、JavaScriptがリクエストに認証トークンを追加することによって行われ、サーバーは正しい認証トークンを含まないフォーム送信を拒否します。

詳細に入る前に、1つの重要なポイントを強調します。「アプリ」の使用のみに制限することはできません。 JavaScriptは、ユーザーのコンピューターのブラウザーで実行されます。その結果、攻撃者は簡単にアプリをリバースエンジニアリングして（ブラウザーでJavaScriptの場合は非常に簡単です）、サーバーでの認証方法を決定し、それを必要に応じて再現できます。ユーザーがアプリを効果的に使用することだけに制限しようとすることは、DRMを実装しようとしていることを意味し、（特にこのような場合は）不可能です。攻撃者にとって事態を困難にすることはできますが、完全に阻止することはできません。それでも、より具体的に質問について話し合いましょう。

ボット

スパムボットから保護するには、まずそれらがどのように機能するかを理解する必要があります。もちろん、ばかげている種類はたくさんありますが、私は2つの一般的な「タイプ」に焦点を当てます（これらのカテゴリーはいくぶん恣意的に選択したことに注意してください）。

多くの単純なボットは、ブラウザー以外のHTTPクライアントを使用してWebサイトからページを要求します（簡単にするために、 curl を使用すると想像してください）。次に、HTMLを解析してフォームを探します。見つかった場合は、フォーム上の入力も確認し、入力を「入力」して、データを使用してHTTPリクエストを作成し、actionプロパティのURLに送信する方法を決定します。フォーム上。ものすごく単純。また、リクエストヘッダー（Origin、User-Agentなど...）の詳細を偽って、通常のユーザーのように見せかけます。
ただし、実際にはブラウザを使用する「より洗練された」ボットがあります。 Selenium のようなものを使用して独自のボットを構築できます。これにより、実際のブラウザーを使用してWebのブラウジングを効果的に自動化できます。ボットはSeleniumを使用してブラウザーにページをロードし、入力フォームをクリックして、キーボード入力を送信し、送信ボタンをクリックします。

「シンプルな」ボットからの保護

ボットの単純なクラスは、サーバーから返されたHTMLを読み取って、サーバーが探している要求の種類を把握し、一致する要求を作成してサーバーに送信します。クライアント認証プロセスでJavaScriptを使用してリクエストに追加の認証情報を添付する場合、その認証プロセスは実際にそのようなボットの正常な実行を停止します。

ただし、ボットを締め出すのは技術的には認証の存在ではありません-ボットを阻止するのは単にJavaScriptを使用することです。 JavaScriptが実行するステップについては何も知りません。このクラスのボットの場合、JavaScriptでフォームの送信をインターセプトし、事前定義されたデータをリクエストに追加して（リクエストデータにnot_a_bot=trueのようなものを追加すると想像してください）、Ajaxで送信します。サーバーは、そのnot_a_bot=trueフラグを含まない要求をすべて拒否します。この種類の信じられないほど単純なチェックは、JavaScriptを実行しないボットを停止します。実際、私は実際にこれを本番システムで使用しており、劇的にボットの提出を削減します。唯一の欠点は、JavaScriptが有効になっていないユーザーもロックアウトされることです（提案されたクライアント認証方法でも可能です）。

では、認証ステップは役に立ちますか？はい！ただし、偶然によるものであり、同じことを達成するためのはるかに簡単な方法があります。

「より洗練された」ボットからの保護

ただし、一部のボットは実際のブラウザーを使用して機能します。つまり、サーバーから渡されたJavaScriptを実行します。その結果、JavaScriptによって実行されるあらゆる種類の自動認証ステップは、これらの種類のボットでも自動的に発生します。実際、これらのボットと通常のユーザーを区別することはほぼ不可能です。

つまり、JavaScriptにnot_a_bot=trueフラグを追加してフォームを保護するか、JavaScriptにリクエストに認証トークンを追加してフォームを保護するかにかかわらず、これらのボットはまったく同じ手順を実行し、サーバーはスパム投稿。攻撃者はアプリをリバースエンジニアリングする必要もありません。独自のJavaScriptにより、スパムボットは保護を回避できます。

これらのボットがフォームに記入するのをどのように停止しますか？費用対効果の高いソリューションは1つだけです：キャプチャシステム（ただしこれは保証ではありません）。

DDoS

DDoSについても言及する価値はありません。 DDoS攻撃は、サーバーが追いつかないほどのトラフィックでサーバーをあふれさせるだけで機能します。ボットからの送信を無視しようとすることで防ぐことができるDDoS攻撃にはいくつかの種類がありますが、最も一般的な種類はそうではありません。多くのDDoS攻撃は、インフラストラクチャに大量のネットワークトラフィックを送信するだけで機能し、追いつくのに十分な帯域幅がありません。その場合、DDoS攻撃を阻止するためにサーバーレベルで実行できることは何もありません。そこでは完全に異なる戦略（主にネットワークレベル）が必要です。これがDDoSに対して役立つかもしれないと示唆した人は誰でも、そのような攻撃がどのように機能するかを理解していません。

概要

だから、物事を分解した後、クライアント認証がまったく利益をもたらさないことがわかります。それは単純なスパムボットを阻止しますが、単純なボットが実行しないJavaScriptを必要とするからです。代わりに、これらの種類のスパムボットをとにかく阻止するはるかに単純な手順があります。さらに、クライアント認証では、実際のブラウザーを使用して作業を行うボットに対する保護は提供されません。優れたキャプチャは、あなたをターゲットにしていないドライブバイボットを少なくとも阻止するかもしれませんが、何もそれらを止めることはありません。