AWS WAF の Challenge と CAPTCHA アクションを用いてボットから保護する

本稿は、2024年7月15日に公開された “Protect against bots with AWS WAF Challenge and CAPTCHA actions” を翻訳したものです。

ボットの脅威から保護するためには、TCP や HTTP ペイロードの署名のようなリクエストのネットワークレベルでの特性を超えて、クライアント環境の洞察が必要とされます。AWS WAF は、CAPTCHA や Challenge アクションを利用して、モバイルデバイスまたはブラウザ上でクライアント側とインタラクションを行い、AWS WAF による許可の前にクライアント環境を理解します。Challenge はクライアント(ブラウザまたはモバイルデバイス)がサイレントに課題を解決することを要求します。CAPTCHA はユーザーのブラウザに人間が解く必要がある課題を提示します。

これらのアクションは、ネットワークからのリクエストで得られる以上にリクエスト元のクライアント環境の可視性を高めることで、Allow、Count や Block アクションを補完します。この可視性は正当なユーザーへのインパクトを最小限に抑えながら、ボットトラフィックを特定して、管理するために有用なメカニズムです。

この投稿では、Challenge や CAPTCHA アクションの動作とそれらを利用した特定のボットの脅威の緩和について説明してします。

Challenge や CAPTCHA アクションがボットを特定し管理するための動作

Challenge や CAPTCHA アクションはブラウザまたはモバイルデバイスとのインタラクションを伴います。このインタラクションは、3 つのステージで構成されます :

クライアントがサイレントに課題を解く必要があるチャレンジ (Challenge) またはパズルを解く人間とのインタラクションを必要とするチャレンジ (CAPTCHA)
クライアント環境を調査してフィンガープリントを生成するクライアント側のスクリプト
AWS WAF が課題の解答を検証してクライアントセッションを一意に識別するトークンを生成するためにフィンガープリントを使用する。このトークンは、以降のリクエストに含まれるもので、CAPTCHA や Challenge アクションをパススルーできるかを検証するためのもの

このインタラクションは 2 つの方法で処理されます :

AWS WAF 統合 SDKs : アプリケーションを AWS WAF に統合することで、これらのステージがアプリケーションやユーザー体験にどのように適合するかを明示的に管理できます。これは、AWS が推奨するアプローチです。
インタースティシャルなインタラクション : AWS WAF はページロードの際に課題を渡すインタースティシャルを含むカスタムレスポンスを提供することでインタラクションのステージを完了します。

これらの 2 つのケースで Challenge や CAPTCHA アクションがユーザーやクライアントとどのようにインタラクションするかを説明します。

Challenge アクションがクライアントとどのようにインタラクションするか

Challenge アクションはユーザーの対応なしにクライアント環境でサイレントチャレンジを実行し、ユーザー体験に明らかな影響を与えることを意図しません。Challenge はクライアントが計算量の高いタスク (proof of work) を完了することを要求します。このアプローチは、アプリケーションにエンゲージしようと試みるボットオペレーターに対してコストを増大させながら、ユーザー環境を評価するためのシームレスなメカニズムを正当なユーザーに提供することを意図しています。

統合 SDK なしで Challenge アクションを利用する (インタースティシャルなインタラクション)

デフォルトで、Challenge アクションはサイレントにチャレンジを完了する JavaScript チャレンジペイロードを利用して HTML リクエスト (Accept: text/html) に応答します。その後、ユーザーは Challenge を要求する後続のルールを通じてリクエストを許可するトークンを利用して、自動的にオリジナルページにリダイレクトされます。図 1 にこのインタラクションのワークフローを示します。

図 1 : ユーザーやブラウザおよびリソースを保護する AWS WAF 間のインタースティシャルな Challenge のシーケンスダイアグラム

アプリケーション統合 SDK を用いた Challenge アクションを利用する

もし、アプリケーション統合 SDK にインテグレーションされていない場合、Challenge アクションをトリガーする非 HTML リクエストは、アセットやフェッチリクエストを中断する HTTP 202 レスポンスを返します。そのため、リクエストがサブミットされる前にクライアントがチャレンジを完了して、クライアントがトークンを取得できるようにアプリケーション統合 SDK をインテグレーションすることを推奨します。図 2 のワークフローでこのインタラクションを説明します。

図 2 : ユーザーやブラウザおよびリソースを保護する AWS WAF 間における SDK 統合利用時の Challenge のシーケンスダイアグラム

アプリケーション統合 SDK を利用したインテグレーションでは、AWS WAF Bot Control または AWS WAF Fraud Control などの少なくとも一つの Amazon マネージドルールを使用する必要があります。投稿済みの「Use AWS WAF CAPTCHA to protect your application against common bot traffic」や「Prevent account creation fraud with AWS WAF Fraud Control – Account Creation Fraud Prevention」を参照してください。2 つのタイプのアプリケーション統合 SDK を利用できます。

JavaScript SDK: この SDK は、ブラウザベースのアプリケーション、特に AWS WAF のルールにより API エンドポイントが一般的にボットの攻撃から保護されているシングルページアプリケーション (SPA) に最適です。それぞれのリクエストで生成され、利用できるトークンを確保するために JavaScript SDK をインテグレートする 3 つのパートがあります。
1. 必須: HTML の head に JavaScript を埋め込みます。これにより、ページロード時にチャレンジが実行されます。
2. 推奨: フェッチ呼び出しをアプリケーション統合 SDK のフェッチラッパー (AwsWafIntegration.fetch) を使うように更新します。これにより、リクエストを送信する前に必ずトークンを取得できます。別の方法として、 AwsWafIntegration.getToken() を使って AWS WAF トークンを取得し、x-aws-waf-token ヘッダーを設定できます。
3. アプリケーションがドメイン間でリクエストを行う場合、トークンドメインを設定します (例えば、www.example.com から api.example.com への API リクエスト)。
Mobile SDK: この SDK は、Android と iOS の両方で利用できます。基本的なワークフローは、AWS ドキュメントで説明されている JavaScript SDK と同様です。

参考 : Challenge アクションを利用した DDoS 脅威からアプリケーションを保護する

ボットオペレーターは、数万のボットを使って同時に小さなリクエストを起動することで、アプリケーションを標的にすることができます。すべてのボットからの同時リクエストの総数はアプリケーションを圧倒する可能性がありますが、IP 当たりのリクエスト数が AWS WAF のレートリミットルールの閾値である 1 分間に 100 リクエストを下回ります( 2024 年 8 月 30 日のアップデートにより、レートリミットの最低閾値を 10 リクエストに設定できるようになりました)。リクエストがアプリケーションに転送される前にチャレンジを完了する必要がある AWS WAF ルールを設定することで、これらの脅威の影響を最小限に抑えることができます。これにより、ボットオペレーターが proof of work を完了する必要があり、オペレーターのコストが増加します。ここでは、エンドポイント /account に対して、すべてのリクエストでチャレンジの完了が必要となる独自のAWS WAFルールを設定します:

AWS WAF Console を開き、次のいずれかを実行する
1. 新しい web ACL を作成するために、Create web ACL を選択する
2. 既存の web ACL を編集するために、ACL の名前を選択する
Rules タブより、Add Rules のドロップダウンから Add my own rules and rule group を選択する
Rule 定義にて
1. ルール名を Name に入力する
2. ルールタイプを Regular rule のままにする
Statement 定義にて図 3 で示すように次の情報を入力する
1. Inspect では URI path を選択する
2. Match type では Exactly matches string を選択する
3. String to match では /account を入力する
Action 定義では Challenge を選択する

図 3 : Challenge アクションに関する AWS WAF コンソールの構成

web ACL にルールを追加するために、Add rule を選択する
web ACL でのルールの優先順位を設定して、Save を選択する
オプション: AWS WAF Bot Control または AWS WAF Fraud Control rule group を利用するなら、AWS WAF アプリケーション統合 SDK をアプリケーションにインテグレーションする
1. AWS WAF コンソールに戻る
2. Application Integration を選択する
3. アプリケーション統合を有効にする Web ACLs に対して構成
  1. web ACL がデプロイされたリージョンをドロップダウンボックスから選択する
  2. Web ACL Name を選択する
  3. JavaScript SDK 構成を拡張する
  4. アプリケーションにコードをコピーする
4. 先の説明のようにアプリケーション内で SDK を設定する

CAPTCHA アクションがクライアントとどのようにやりとりするか

CAPTCHA アクションでは、リクエストが成功する前に人間がパズルを解く必要があります。このパズルは、ユーザーが人間であることを証明することが目的です。図 4 は、ユーザーが解く必要のある 2 種類のパズルを示します。

図 4 : AWS WAF CAPTCHA の課題

アプリケーション統合 SDK を利用せず CAPTCHA アクションを使用する

アプリケーションに対して統合 SDK を利用せず CAPTCHA アクションを使用する場合、CAPTCHA アクションをトリガーとする HTML(Accept: text/html) へのリクエストは、CAPTCHA パズルを提示するページを返し、バックグラウンドでチャレンジを解決します。CAPTCHA を解決した後、AWS WAF がトークンを発行し、トークンの有効期限まで CAPTCHA アクションを含むルールを通過する後続のリクエストを許可します。トークンについては後で詳しく説明します。図 5 のワークフローは、ユーザー、ブラウザ、AWS WAFの相互作用を示します。

図 5 : ユーザーやブラウザおよびリソースを保護する AWS WAF 間におけるインタースティシャルな CAPTCHA でのインタラクションのシーケンスダイアグラム

CAPTCHA JavaScript API を用いた CAPTCHA アクションを利用する

CAPTCHA JavaScript API は、CAPTCHA アクションで保護されたリソースにリクエストが送信される前にいつでも、フロントエンド Web アプリケーション内で CAPTCHA パズルを表示する機能を提供します。これにより、バックグラウンドでもチャレンジが完了します。text/html ではないアセット(画像、JavaScript) やフェッチリクエストが、フロントエンド Web アプリケーションとユーザー体験を中断する可能性のある HTTP 405 レスポンスコードを受け取るため、これが推奨されるアプローチでです。図 6 のワークフローは、AWS WAF トークンを生成するために必要なインタラクションを示しています。投稿済みの「Use AWS WAF CAPTCHA to protect your application against common bot traffic」でアプリケーションに CAPTCHA JavaScript API をインテグレーションするための手順や React で CAPTCHA JavaScript API をインテグレーションするコードサンプルについて記載しています。AWS WAF CAPTCHA は、モバイルデバイスではサポートされていません。

図 6 : ユーザーやブラウザおよびリソースを保護する AWS WAF 間における CAPTCHA SDK でのインタラクションのシーケンスダイアグラム

参考 : IP 評価に基づいて人間が CAPTCHA を完了することを要求する

IP 評価ルールは、ボットや他の脅威トラフィックに一般的に関連付けられている IP アドレスを特定し、ブロックすることに役立ちます。例えば、AWSManagedIPDDoSList ルールを使用することで、AWS 脅威インテリジェンスが DDoS アクティビティを特定して関連する IP トラフィックをブロックできます。もし、正規のユーザーがボットオペレーターが管理するネットワーク上の別のデバイスと同じ IP アドレスを共有している場合、問題になる可能性があります。代わりに、アプリケーションへのリクエストを送信する前に CAPTCHA を解決することを正規のユーザーに要求することで、このルールを通じて正規のユーザーを許可できます。

AWS WAF Console を開き、次のいずれかを実行する
1. 新しい web ACL を作成するために、Create web ACL を選択する
2. 既存の web ACL を編集するために、ACL の名前を選択する
Rules タブより、Add Rules のドロップダウンから Add managed rule groups を選択する
web ACL に Amazon IP reputation list ルールを追加する。そのとき、ルールを編集するために Edit を選択する
Amazon IP reputation list rules に対して以下を参照
1. 図 7 で示すように、AWSManagedIPDDoSList に CAPTCHA を選択する

図 7 : CAPTCH で上書きした Amazon IP reputation rule の設定

設定を保存するために、Save を選択する
web ACL に Amazon IP reputation list rules ルールグループを追加するために、Add rules を選択する
web ACL でのルールの優先順位を設定して、Save を選択する
オプション: CAPTCHA JavaScript SDK を利用してアプリケーションにインテグレートする

トークンがどのように動作するか

Challenge および CAPTCHA アクションの結果、AWS WAF はトークンを生成します。トークン自体は暗号化、改ざん防止がされており、aws-waf-token の cookie として実装されます。トークンはユーザーには意識されないものですが、クライアントセッションを識別するのに役立つ詳細情報を含んでいます。これらの詳細には以下のものが含まれます:

タイムスタンプ: トークンが生成された時間。デフォルトでは、クライアントは 5 分間再チャレンジされません。ウェブACL のためのイミュニティ時間の設定については、AWSのドキュメントに記載があります。
ブラウザのフィンガープリント: クライアントのブラウザ環境のデータポイントの集合体から生成されたハッシュ。これにはブラウザのプラグイン、JavaScript の環境、および他の特性が含まれます。
解決済みのパズルタイプ: Challenge または CAPTCHA (あるいはその両方)が完了したかどうか。
トークンドメイン: AWS WAF が受け入れるリクエストを送信しているドメイン。デフォルトでは、クライアントのホスト名に、たとえば、www.example.com などに基づいて設定され、またトークンクッキーに対して使用するようにセットされます。このクッキーとトークンは、リクエストごとに www.example.com へ送信されます。このドキュメントにあるようにフロントエンドアプリケーションや WebACL でトークンドメインを更新することができます。これは、www.example.com で実行されるシングルページアプリケーション (SPA) や api.example.com で実行される API などがある場合に便利です。トークンドメインを .example.com に設定するとブラウザが example.com 配下のすべてのサブドメインでトークン/クッキーを送信します。トークンドメインの設定の詳細については、ドキュメントをご覧ください。

ボットトラフィックの管理のために、Challenge、CAPTCHA およびトークンがどのように使用されるか

これらのアクションと生成されたトークンには、ボットトラフィックの識別と管理に役立つ以下のような特徴があります:

完全なクライアントを要求: Challenge アクションと CAPTCHA アクションはクライアント側のスクリプトを実行できるクライアントを必要とします。これにより、JavaScript を実行できないシンプルな HTTP リクエストベースのボットを抑制します。
ボットオペレーターのコストを上げる: Challenge と CAPTCHA パズルを解決するためには、ボットオペレーターがより高度なボットの構築と運用に投資する必要があります。これは、アプリケーションを使うボットにとってさらなる参入障壁となります。
クライアントを一意に識別: 同一の IP アドレスを共有したり、IP アドレスを切り替えたりするクライアントも一意のトークンによって区別できるため、単一のホスト/ IP から複数のクライアントを簡単に模倣することができません。
クライアント環境のフィンガープリント: トークンで提供されるフィンガープリントは、ボットの自動化の兆候となるブラウザやモバイルデバイスの設定を識別するのに使えます。

結論

この投稿では、AWS WAF を用いた Challenge や CAPTCHA の動作や高度なボットの脅威を緩和するためのこれらの使い方について説明しました。CAPTCHA and Challenge actions best practices のドキュメントでは、これらのアクションを最大限に活用するガイダンスが提供されています。

著者について

David MacDonald

David は、ニュージーランドのスタートアップ企業がセキュアでスケーラブルなソリューションを構築できるよう支援をするシニアソリューションアーキテクトです。彼のキャリアのほとんどは、様々な業界に対してサービスを提供する SaaS プロダクトの構築と運用に費やされています。

Jess Izen

Jess Izen は、AWS WAF のシニアソフトウェア開発エンジニアとして、Bot Control や Fraud Control のようなプロダクトを構築しています。彼女は、パフォーマス重視で同時実行される Rust サービスや Kafka や Redis/Valky などの技術を含む分散システムの開発に取り組むことを好みます。時間があるときには、自転車に乗ったり、アマチュアのムエタイに出場したりしています。LinkedIn で彼女と繋がることができます。

翻訳は、パートナーセールスソリューションアーキテクトの小林が担当しました。

Amazon Web Services ブログ