CAPTCHA および Challenge アクションを使用するベストプラクティス - AWS WAF、 AWS Firewall Manager、および AWS Shield Advanced

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

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

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

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

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

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

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

AWS WAF が GET text/html リクエストに応答して CAPTCHA パズルとサイレントチャレンジのみを送信するように 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 and Challenge アクションの動作」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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