CAPTCHA および Challenge アクションを使用するベストプラクティス

このセクションのガイダンスに従って、 AWS WAF CAPTCHA またはチャレンジを計画および実装します。

CAPTCHA およびチャレンジの実装の計画

ウェブサイトの使用状況、保護するデータの機密性、リクエストのタイプに基づいて、CAPTCHA パズルまたはサイレントチャレンジを配置する場所を決定します。必要に応じてパズルを提示できるように、CAPTCHA に適用するリクエストを選択します。ただし、役に立たずにユーザーエクスペリエンスを低下させる可能性がある場合、パズルの提示を控えてください。Challenge アクションを使用して、エンドユーザーへの影響が少ないサイレントチャレンジを実行しますが、リクエストが JavaScript 有効なブラウザから送信されたことを確認するのに役立ちます。

CAPTCHA パズルとサイレントチャレンジは、ブラウザが HTTPS エンドポイントにアクセスしている場合にのみ実行できます。トークンを取得するには、ブラウザクライアントが安全なコンテキストで実行されている必要があります。

クライアントで CAPTCHA パズルやサイレントチャレンジを実行する場所を決定

CSS や画像のリクエストなど、CAPTCHA による影響を受けたくないリクエストを特定します。CAPTCHA は必要な場合にのみ使用してください。たとえば、ログイン時に CAPTCHA チェックを行う予定で、ユーザーが常にログインから別の画面に直接ダイレクトされる場合、2 つ目の画面で CAPTCHA チェックを要求することはおそらく不要であり、ユーザーエクスペリエンスを低下させる可能性があります。

GET text/html がリクエストに応答して CAPTCHA パズルとサイレントチャレンジ AWS WAF のみを送信するように Challengeと CAPTCHAを設定します。POSTリクエスト、クロスオリジンリソース共有 (CORS) プリフライトOPTIONS要求、またはその他の非要求GETリクエストタイプに応答しても、パズルもチャレンジも実行することはできません。他のリクエストに対するブラウザの動作は異なる場合があり、インタースティシャルを適切に処理できない可能性があります。

クライアントが HTML を受け入れられても、CAPTCHA またはチャレンジインタースティシャルを処理できない場合があります。たとえば、小さな iFrame を持つウェブページ上のウィジェットは HTML を受け入れますが、CAPTCHA の表示またはその処理ができない場合があります。このようなタイプのリクエストのルールアクションは、HTML を受け入れないリクエストと同じように、設定しないでください。

以前に取得したトークンの確認に CAPTCHA または Challenge を使用

ルールアクションは、正規ユーザーが常にトークンを持っている必要がある場所で、有効なトークンの存在を確認する場合にのみ使用できます。このような状況では、リクエストがインタースティシャルを処理できるかどうかは関係ありません。

例えば、 JavaScript クライアントアプリケーションの CAPTCHA API を実装し、保護されたエンドポイントに最初のリクエストを送信する直前にクライアントで CAPTCHA パズルを実行する場合、最初のリクエストにはチャレンジと CAPTCHA の両方に有効なトークンが常に含まれている必要があります。 JavaScript クライアントアプリケーション統合の詳細については、「」を参照してくださいAWS WAF JavaScript 統合。

この状況では、ウェブ ACL に、この最初の呼び出しと一致するルールを追加し、Challenge または CAPTCHA ルールアクションでルールを設定することができます。ルールが正規のエンドユーザーとブラウザに一致すると、アクションは有効なトークンを検索します。したがって、アクションがリクエストをブロックしたり、リクエストに応答してチャレンジや CAPTCHA パズルを送信したりすることはありません。ルールアクションの仕組みの詳細については、「CAPTCHA および Challenge アクション動作」を参照してください。

CAPTCHA および Challenge で機密性のある非 HTML データを保護する

次のアプローチで、API などの機密性の高い非 HTML データに CAPTCHA および Challenge 保護を使用できます。

1. HTML レスポンスを受け取り、機密性の高い HTML 以外のデータに対するリクエストの近くで実行されるリクエストを特定します。

2. HTML のリクエストと照合し、機密データのリクエストと照合する CAPTCHA または Challenge ルールを記述します。

3. CAPTCHA および Challenge イミュニティ時間の設定を調整し、通常のユーザーインタラクションで、クライアントが HTML リクエストから取得するトークンが、機密データのリクエストにおいて利用可能で有効期限が切れないようします。チューニングの情報については、「タイムスタンプの有効期限： AWS WAF トークンのイミュニティ時間」を参照してください。

機密データのリクエストが CAPTCHA または Challenge ルールに一致すると、クライアントが以前のパズルまたはチャレンジからの有効なトークンをまだ持っている場合、そのリクエストはブロックされません。トークンが利用できない、あるいはタイムスタンプが有効期限が切れている場合、機密データをアクセスするリクエストは失敗します。ルールアクションの仕組みの詳細については、「CAPTCHA および Challenge アクション動作」を参照してください。

CAPTCHA および Challenge を使用して既存ルールの調整

既存のルールを確認し、変更するか追加するかを確認します。一般的なシナリオをいくつか次に示します。

• トラフィックをブロックするレートベースルールがあるものの、正規ユーザーのブロックを避けるためにレート制限を比較的高く維持する場合、ブロックルールの後に 2 つ目のレートベースルールを追加することを検討してください。2 つ目のルールにブロッキングルールよりも低い制限を設定し、ルールアクションを CAPTCHA また Challenge に設定します。ブロッキングルールは、高すぎるレートでリクエストを受け取らないように引き続きブロックします。新しいルールは、ほとんどの自動化トラフィックをさらに低いレートでブロックします。レートベースルールの詳細については、「レートベースのルールステートメント」を参照してください。

• リクエストをブロックするマネージドルールグループがある場合、一部またはすべてのルールの動作を Block から CAPTCHA または Challenge に切り替えることができます。これを行うには、マネージドルールグループの設定で、ルールアクション設定をオーバーライドします。ルールアクションのオーバーライドの情報については、「ルールグループのルールアクションの上書き」を参照してください。

デプロイする前に CAPTCHA およびチャレンジの実装をテストしてください

すべての新機能については、AWS WAF 保護機能のテストと調整 のガイダンスに従ってください。

テストのとき、トークンタイムスタンプの有効期限要件を確認し、ウェブ ACL およびルールレベルのイミュニティ時間を設定して、ウェブサイトへのアクセスを制御および顧客に優れたエクスペリエンスを提供することのバランスが適切に維持できるようにします。詳細については、「タイムスタンプの有効期限： AWS WAF トークンのイミュニティ時間」を参照してください。