AWS WAFのcaptchaを解説：仕組みと対処方法
AWS WAF captchaは、サイト運営者が訪問者を確認するように設定したときに、AmazonのWeb Application Firewallが配信するチャレンジです。ファイアウォールが不審と判断したリクエストには、コンテンツの代わりにチャレンジページが返されます。訪問者は、本来のページが読み込まれる前に確認を通過しなければなりません。テストやデータ収集の途中でこれに遭遇したら、見分け方、サイト運営者が管理している項目、そしてScarnoxで今できることを知っておく必要があります。このガイドでは、その3点を扱います。
AWS WAF captchaとは
AWS WAFは、Webアプリケーションの前段に置かれるルールエンジンです。Amazon CloudFront、Application Load Balancer、API Gatewayで使われます。ルールはリクエストを許可、ブロック、カウント、またはチャレンジできます。チャレンジは、ルールの設定によって、サイレントなJavaScriptチェックのこともあれば、目に見えるcaptchaパズルのこともあります。
重要なのは、判断を下すのがサイト運営者だという点です。ファイアウォールはスクレイパーの目的を知りません。見えているトラフィックだけを評価します。リクエストの頻度、IPの評判、ヘッダー、クライアントの振る舞いです。
コードでの見分け方
AWS WAFのチャレンジは、レスポンスから見分けられることがよくあります。よくあるシグナルはx-amzn-waf-actionレスポンスヘッダーで、チャレンジは本来のページが表示される前にHTTPステータス202で返されることが多いです。サイトによってファイアウォールの設定は異なるため、これらは証拠ではなく手がかりとして扱ってください。
import requests
def looks_like_aws_waf(resp: requests.Response) -> bool:
# ヘッダーは手がかりであって証拠ではない。テスト中のページで必ず確認すること。
return "x-amzn-waf-action" in resp.headers
resp = requests.get("https://example.com/products", timeout=30)
if looks_like_aws_waf(resp):
print("Challenge served. Stop, slow down, and check your request rate.")
else:
print("Status", resp.status_code)ページのソースに、AWS WAFのチャレンジパスから読み込まれたスクリプトがないか、スクリプトが動くまで中身が表示されないページがないかも確認してください。素のrequests呼び出しでは、データではなくチャレンジページが返ってくることがよくあります。これは想定どおりです。
サイト運営者ができること
自分でサイトを運営しているなら、AWS WAFのコンソールでチャレンジを発生させるルールを調整できます。特に有用な設定は次のとおりです。
- レートベースのルール。 過剰なリクエストを送るクライアントだけにチャレンジし、通常の訪問者は通過させる。
- 許可リスト。 自社の監視、CI、パートナーのIP範囲を許可して、自分のテストがチャレンジされないようにする。
- 機微なパスだけにチャレンジする。 サイト全体ではなく、ログインや決済などのパスだけに適用する。
自分のサイトをテストしている場合、最も確実な対処は、テストランナーを許可リストに入れることです。自分が管理していないサイトでチャレンジを回避しようとしてはいけません。それはサイト運営者の保護であり、それを破ると真っ先にアクセスが失われます。
Scarnoxでのサポート状況
- 現在ライブ： PopularCaptcha（プロキシなしと、自分のプロキシを使う場合）。
- 近日対応予定： AWS WAF。GeeTest、reCAPTCHA v2とv3、Cloudflare Turnstile、Arkoseも同様です。AWS WAFの解決に依存する本番フローは、ライブとして掲載されるまで設計しないでください。
そのため、作業が許可されているサイトが今日AWS WAFのチャレンジを表示する場合の選択肢は、上で挙げたものです。速度を落とす、自分のサイトなら許可リストを使う、またはサイトの運営者にAPIやデータフィードを依頼する、のいずれかです。アカウントを作成して無料のトライアルクレジットで始めれば、カード登録は不要です。今PopularCaptchaのフローを組んでおき、AWS WAFのサポートが始まったときに備えられます。現在の料金は料金ページにあります。
AWS WAFの背後にある自社サイトのテスト
自分がサイトの運営者で、実際の訪問者のためにファイアウォールを弱めることなく、自動テストをファイアウォールに通したい場合は、チャレンジを回避するのではなく、ファイアウォール自身のツールを使ってください。
- 新しいルールをカウントモードで作成します。誰にも影響を与えずに、チャレンジされていたはずのリクエストを記録するので、テストが何を引き起こしているかを正確に確認できます。
- WAFのログを、Amazon CloudWatch Logs、Amazon S3、またはAmazon Data Firehoseに有効にします。ログには、どのルールが一致したか、どのヘッダーやパスが原因かが記録されます。
- テスト環境には、独立したルールセットを持つ専用のステージングドメインを用意します。こうすれば、本番は保護されたまま、テストスイートを自由に走らせられます。
- テストランナーが使うIP範囲やヘッダーの値だけを許可リストに入れ、ランナーを変えるたびにその一覧を見直します。
これらの手順はファイアウォールの保護を維持しつつ、テストのトラフィックを予測可能にします。それが本当に必要な結果です。テストの設定を変えるたびにルールを見直してください。先月のランナーには正しかったルールが、今はそのランナーをブロックしているかもしれません。
責任あるスクレイピング
AWS WAFのページに当たる理由がデータ収集であるなら、次の点に注意してください。
- リクエストを送る前に、サイトの
robots.txtと利用規約を読んでください。 - リクエストの頻度は低く保ってください。チャレンジは、サイトが速度を落としてほしいと伝えている場合が多いです。
- サイトが明らかに自動化されたアクセスを望んでいないときは止めてください。
- 持つ理由のない個人データは収集せず、収集したデータは適用されるプライバシー規則のもとで扱ってください。