スパムがレート制限付きの問い合わせフォームを破った理由

レート制限付きのお問い合わせフォームを、なぜスパムが通り抜けるのでしょうか？ レート制限はアドレスごとにリクエストを数えるだけで、誰が送ったのかを問う仕組みを何も持たないからです。10月30日と11月2日、2つの脆弱性スキャナーが私のサイトをクロールし、フォームのあるトップページを普通の訪問者と同じように読み込み、有効なCSRFトークンを手に入れ、立ち去るかブロックされるまでフォームに投稿し続けました。初日は101件、2日目は31件の投稿が通りました。どれもアプリが200を返したもので、アプリは送信のときにも、送信に失敗したときにも200を返します。つまりこの数字は、生じえたメールの最大数です。¹² アドレスごとに1分5件に設定した私のアプリのリミッターは、それぞれの日に830件と31件の投稿を拒否し、101件と31件の送信を通しました。その設定の正確なリミッターが許したはずの数より、47件と9件多い数です。³ エッジのレート制限は、どちらのスキャナーにも一度も発動しませんでした。1回目のフラッドでは、最後のフォーム投稿から約12分後に私がそのルールを作ったからです。2回目のスキャナーの投稿は2つのCloudflareデータセンターを経由して届き、データセンターごとにカウンターは別々です。この分割が2回目の沈黙について私が持つ最も有力な説明で、1分ごとの合計と矛盾しませんが、合計でそれを証明することはできません。⁴⁵⁶ 私のスタジオのサイトでは、ハニーポットのフィールドが8日間で52件中42件の送信を捕らえ、送り手がハニーポットを空のままにした10件を通しました。⁷⁸ このサイトのエッジには、人間がそこにいるかを問えるルール、つまりフォームのパスに対するマネージドチャレンジがありました。しかしそれは一覧にあるユーザーエージェント文字列にしか発動せず、2つのスキャナーはどちらもブラウザーの文字列を送っていました。高い脅威スコアをキーにした2つ目のチャレンジは、Cloudflareが現在そのスコアを常にゼロにしているため、決して発動しえませんでした。こうして、すべての送信にその問いを投げるものは何もありませんでした。⁹¹⁰⁴¹¹ 11月3日の朝からは、私の受信箱に届きうるすべての送信に対して、両方のフォームでTurnstileがその問いを投げています。¹²

TL;DR

• 2つのスキャナー、1つの受信箱。 10月30日、あるアドレスが1分単位の53個のバケットにわたって私のサイトに76,429件のリクエストを送りました。11月2日には別のアドレスが22個のバケットにわたって10,907件を送りました。どちらもサイト全体をクロールし、どちらもパスとUser-Agentヘッダーの両方にSQLインジェクションの文字列を入れ、どちらもお問い合わせフォームに投稿しました。その数は初日が1,065回、2日目が500回です。¹³¹⁴¹²
• 有効なCSRFトークンが証明するのは、私のサイトが発行したトークンをクライアントが持っていたことだけです。 両日のすべての送信がトークンを持っていました。私のトークンはステートレスなので、ページを取得したクライアントなら誰でも1つ手に入れられるからです。2回のフラッドを通して、CSRFチェックが拒否した投稿は4件でした。¹⁵¹⁶
• 私自身のリミッターが漏れていました。 リミッターはCloudflare KVからカウンターを読み、比較し、もう一度読んでから、カウントに1を足した値を別のリクエストで書き込みます。2回目の読み取りに失敗すると1が書き込まれ、KVの呼び出しに失敗すると1つのプロセスのメモリーに保持したカウントにフォールバックします。どの経路でも5件を超えて通すことがありえ、どの経路がそうしたのかはログからはわかりません。上限5件に対して、1分間に18件の送信が出ていきました。¹⁷¹
• エッジのレート制限は、データセンターごと、アドレスごとに数えます。 11月2日、18:56から19:05:00 UTCまで、つまりブロック前後の数分間のスキャナーのフォーム投稿85件は、アムステルダム（44件）とロンドン（41件）を経由して届き、最も多い1分間は2つの間で18対14に分かれていました。この分割が、ルールが沈黙していた最もありそうな理由ですが、1分ごとの合計でそれを証明することはできません。翌朝に私が行ったプローブで、ルールが発動すること、そしてCloudflareがそれを記録することは証明されました。⁵¹⁸
• ブロックはアドレス単位のブロックで、どちらもメールを止めるには遅すぎました。 10月30日、私は気づいてから3.9分後、そのアドレスの最初のフォーム投稿から約50分後に、手作業でアドレスをブロックしました。11月2日は、スキャンの最初の1分から8分後に私のモニターがブロックしました。どちらの日も、ブロックの入った分より後に出た送信はありません。10月30日は最後の送信がブロックの12分以上前で、11月2日はブロック前の数分間に26件、ブロックの分そのものに5件ありました。後者の5件は、1分単位のデータではブロックの秒より前か後かを決められません。¹⁰¹⁹¹²
• ハニーポットは、すべてのフィールドを埋めるボットを捕らえます。 私のスタジオのサイトでは、ハニーポットが52件中42件の投稿に成功したかのように応答し、何も保存しませんでした。到着した時間帯で照合すると、Torの出口ノードからの送信はすべてその中に含まれていました。保存された10件、つまりメールにして最大10通は、ハニーポットを空のままにした送り手からのものでした。⁷²⁰
• 変えたこと。 両方のフォームに、マネージドモードのCloudflare Turnstileウィジェットを置きました。サーバーは、Cloudflareのsiteverify APIが送信のトークンを受け入れるまで何も保存も送信もせず、トークンがない場合、大きすぎる場合、検証できない場合は拒否します。Turnstileは訪問者のブラウザーでチャレンジを実行し、IPアドレス、TLSフィンガープリント、ユーザーエージェントといったシグナルを処理します。Cloudflareは、フォームの入力内容には触れないとしています。人間が手でスパムを打ち込むことは止められず、量を抑えるレート制限の代わりにもなりません。¹²²¹²²

1. 問い：「それはあなた？」

11月2日、私の受信箱がお問い合わせフォームのメッセージで埋まりました。最初の問いは、私のインフラを動かしているエージェントのセッションに向けたもので、私自身の自動化がそれを送っているのか、というものでした。違いました。送っていたのはスキャナーで、このサイトのお問い合わせフォームを通していました。私のスタジオのサイト941apps.comのフォームも独自に少量ずつの投稿を受けていましたが、その日、受信箱に届いたものはありませんでした。²³⁸ モニターのアラートと2つのフォームという3つのメールの流れは、すべて私自身のメールドメインの1つのアドレスから送られるので、受信箱では見分けがつきませんでした。²³

件名が正体を明かしていました。このサイトのお問い合わせハンドラーは、送信内容を「Contact Form:」という件名に、送り手が名前の欄に入力したものを続けて私に送ります。そのため、スキャナーのペイロードがそのまま件名になるのです。²⁴²³ スタジオのサイトのフォームは、メッセージをデータベースに保存してから、同じ受信箱にメールで送ります。²⁵

最初に投げた問いは間違っていました。正しい問いに答えるには、1日がかりのクエリが必要でした。その問いとは、これらのフォームにある制御のうち、どれがスキャナーと人間を見分けられたのか、そしてそれぞれがなぜ残りを通したのか、です。制御は5種類ありました。このサイトには、カスタムルールを持つエッジのファイアウォール、エッジのレート制限、CSRFトークン、そしてアプリ内のレートリミッター。スタジオのサイトには、同じ種類のエッジのルール、エッジのレート制限、観測されたフォーム投稿を1件も拒否しなかったアプリ独自のリミッター、そしてハニーポットのフィールドです。⁹²⁵⁷ この記事の残りでは、2回のフラッドと少量ずつの投稿を1つずつ取り上げ、続いて5つの層を1つずつ、それぞれのルールの文面やコードの挙動とともに見ていきます。

数字の出どころ

以下の件数はすべて、2つのゾーンについてのCloudflareのリクエスト分析とファイアウォールイベント（11月3日に、すでに閉じた時間枠に対してクエリしたもの）、スタジオのサイトのメッセージテーブル、そして私のモニター自身のログから来ています。¹⁶ スクリプトが保存したクエリ結果を数百行の台帳に変換し、各行にはそれを生んだルールが付いています。この記事の数字は台帳とその補遺からだけ取り、それ以外からは取っていません。当日のメモと台帳が食い違う場合は、台帳を優先します。10月30日のメモはフラッドの数分後、Cloudflareがまだ最後の数分を取り込んでいる最中に書いたもので、数え漏れがあります。¹⁶²⁶ Cloudflareはこれらのデータセットを「at least 31 days of data on every plan」（すべてのプランで少なくとも31日分のデータ）保持するので、フラッドを後から数えることはできましたが、いつまでもできるわけではありません。²⁷

2種類の数字には注意が必要です。ファイアウォールイベントはサンプルなので、どのルールがいつ動いたかに使い、件数にはリクエストのデータセットを使います。¹⁶ また、このサイトで200が返ったフォーム投稿は、送信か、ハンドラーが同じく200を返す失敗（そうした失敗の経路は2つあります）のどちらかであって、配信されたメールではありません。メールサービス側のログも確認していません。したがって、この記事のメールの件数はすべて上限です。²⁴²⁸

平常時の姿

フラッドの前、フォームは静かでした。クエリが対象とする8日間で、2つのスキャナー以外にフォームへの投稿に成功したアドレスは3つで、どれもちょうど2回ずつ、10月27日、28日、29日に1日1アドレスでした。²⁹ それが人間だったかどうかはわかりません。1つのアドレスからの2回の投稿はダブルクリックとも合いますし、再試行するボットとも合います。この不確かさこそ、問題全体の縮図です。ログも制御も、それを言い当てられなかったのです。

2. 1回目のフラッド：10月30日、手作業でブロック

1回目のフラッドは、地域インターネットレジストリがBULLIONET FBW NETWORKS SASの名義で登録している、フランス登録のネットワーク上の1つのアドレスから来ました。³⁰ 最初のリクエストは17:59 UTCの分（太平洋夏時間10:59）に、最後のリクエストは18:51の分（11:51 PDT）に届きました。1分単位のバケット53個で、このサイトへのリクエストは76,429件です。そのアドレスについての1分ごとのクエリと、私のアカウントのすべてのゾーンを横断するクエリという2つの独立したクエリがこの合計で一致し、このアドレスはその前にも後にも何も送っていません。¹³

スキャンの形

フォームはその一部にすぎませんでした。ブロック前、このアドレスは1分あたり平均1,389.7件のリクエストを送り、18:36の分に3,219件のピークに達し、サイト全体を歩き回りました。異なるパスは少なくとも2,881個です。パスのクエリが行数の上限に達したので、これは下限です。¹³³¹ スキャン全体での結果の内訳は次のとおりです。¹³

エッジの7.3%はほぼすべてがブロックによるもので、5,587件の拒否のうち5,234件はブロックの入った分より後のものです。¹³ それまでの50分間に動いていたのは、エクスプロイトのパスを対象とするルールだけでした。そのルールは最初の1分から機能しており、最初のファイアウォールイベントは17:59:53 UTCです。ただしこのルールは.phpや/wp-のようなパスの部分文字列に一致するもので、このスキャンの大半は実在するページを要求していました。¹⁰⁹

これをクロールではなくスキャンにしていたのは、リクエストに何を入れていたかです。トラフィックのほぼすべて、少なくとも69,322件のリクエストが、Windows用のごく普通のChrome 141のユーザーエージェントを1つ使っていました。さらに少なくとも2,755件はGooglebotを名乗っており、エッジの検証済みボットのルールはそれらをGoogleとして扱いませんでした。³² 少なくとも3,154件のリクエストはUser-Agentヘッダーそのものに、少なくとも396種類の文字列でSQLインジェクションのペイロードを入れていました。少なくとも2,680件のリクエストはパスにペイロードを入れており、異なるパスは少なくとも810個です。³²³¹ これらのペイロードは、文書化されたファミリーに属します。PG_SLEEP(15)、waitfor delay '0:0:15'、XOR(if(now()=sysdate(),sleep(15),0))は時間ベースのプローブです。PortSwiggerのチートシートはOracle、Microsoft SQL Server、PostgreSQL、MySQLの遅延の構文を挙げており、sqlmap自身のペイロード定義にも同じ関数が含まれています。³³³⁴ PortSwiggerは、それが機能する理由を「As SQL queries are normally processed synchronously by the application, delaying the execution of a SQL query also delays the HTTP response.」（SQLクエリは通常アプリケーションによって同期的に処理されるため、SQLクエリの実行を遅らせるとHTTPレスポンスも遅れる）と述べています。³⁵ 遅い応答が1回あっても、ほとんど何も証明しません。ペイロードが求めるたびに約15秒の遅延が戻ってきて、ペイロードのない対照リクエストでは戻ってこない。それがインジェクションの可能性の証拠になります。

このサイトのペイントアプリには共有用のエンドポイントがあり、スキャナーはそれを見つけました。共有パスに320件のPOSTを送っています。クエリが対象とする8日間でそこに投稿したアドレスはこれだけで、エンドポイントは320件すべてを拒否し、何も保存しませんでした。その前後には、/paint/share'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15)||'や/paint/(select 198766*667891 from DUAL)のようにペイロードを組み込んだパスの変種にも投稿し、サイトはそれらに404を返しました。³¹ このアドレスは私のアカウントのもう1つのゾーンにも触れており、kiradex.appに387件のGETを送ってすべて200を受け取りました。ほかのゾーンには触れていません。¹³ 私の読みでは、このサイトからそのサイトへのリンクをたどったのでしょう。リンクは確認していません。

OWASPの自動化された脅威のカタログには、この活動を表す名前があります。OAT-014、Vulnerability Scanning（脆弱性スキャン）で、「Crawl and fuzz application to identify weaknesses and possible vulnerabilities.」（アプリケーションをクロールしファジングして、弱点と脆弱性の可能性を特定する）とあります。³⁶ お問い合わせフォームは、ファジングする入力がもう1つ増えただけでした。

フォーム、1分ごと

このアドレスはお問い合わせフォームに1,065回投稿し、そのすべてがアプリに届きました。エッジは1件も止めていません。¹ 最初の投稿と最初の送信は18:00 UTCの分（11:00 PDT）に来ました。以下は、フォーム投稿がアプリに届いたすべての分を、アプリが返したステータス別に示したものです。¹

合計は、送信101件、アプリのリミッターによる拒否830件、必須項目の欠落による拒否130件、CSRFチェックによる拒否4件で、この4件はすべて18:03の分です。¹ 429はアプリが返したものです。エッジのレート制限ルールはまだ存在しておらず、このアドレスについてレート制限のファイアウォールイベントは1件もありません。Cloudflareがこれらの投稿についてオリジンのステータスを記録している範囲では、429はオリジンから来ています。¹⁰³⁷ 422はFastAPIのフォームバリデーションによるもので、これはリミッターより先に実行されるため、リミッターの枠を消費しませんでした。この順序は10行のFastAPIアプリで確かめました。必須項目を欠いた投稿は、ラッパーを一度も呼ばずに422を返しました。³⁸ 18:37の129件のまとまりは、スキャナーがフィールドを落としながらフォームをファジングしていたように見えます。

「送信」の列をリミッターと照らし合わせて読んでください。リミッターはアドレスごと、時計の1分ごとに5件の投稿を許しますが、そのうち8つの分で5件を超える送信が出ており、18:06には18件でした。¹³ 理由は第4節で説明します。

気づき、そしてブロック

私は11:46 PDTに気づき、何かがサイトのお問い合わせフォームを繰り返し叩いている、と書き留めました。²⁶ その時点で最初のフォーム投稿から約46分がたっており、フォームへのフラッド自体は11:37 PDTに終わっていました。¹ 私はそのアドレスを、ゾーンの最初のカスタムルールがすでに照合しているアカウントレベルのブロックリストに手作業で追加しました。そのルールの最初のイベントは18:49:53 UTC（11:49:53 PDT）です。¹⁰ ブロックは、私が気づいてから3.9分後、最初のフォーム投稿から約50分後、スキャンの最初の1分から50.9分後に入りました。¹¹³ 101件の送信はすべてその前に出ていました。アプリに届いた最後のフォーム投稿は、ブロックの約12分前です。¹ ブロックの入った分の後、このアドレスはさらに5,234件のリクエストを送り、エッジはそのすべてを拒否しました。¹³

同じ秒、18:49:53 UTCに、私はゾーンで唯一のレート制限ルールを作りました。お問い合わせとペイント共有のパスへのフォームのPOSTを対象に、アドレスごとに10秒あたり3件、10秒間ブロックするものです。⁹ 18:52:38 UTCに自分のマシンからそれをテストしました。そのテストについての私のメモには、ブラウザーのユーザーエージェントで有効なCSRFトークンを持たない6件の投稿を1秒間隔で送ると「returned 403 403 403 429 429 429 (the app’s CSRF rejection, then the edge’s rate limit)」（403 403 403 429 429 429を返した（アプリのCSRF拒否、続いてエッジのレート制限））とあり、素のcurlによる投稿は既存のカスタムルールがマネージドチャレンジを返したため、そもそもこのルールに届きませんでした。²⁶ メモには投稿がトークンを持っていなかったとありますが、11月3日の私のプローブが示したとおり、そのフィールドを欠いた投稿はハンドラーが動く前に422になります。したがって403は、トークンが存在していて有効でなかったことを意味します。¹⁸ ファイアウォールイベントもこれと一致します。私のテスト用アドレスからのレート制限イベントが3件（最初の1件はその秒）、そして私のcurlの投稿に対するマネージドチャレンジが24件です。³⁹ 私のテストのトラフィックは、上記のどの件数にも含まれていません。

その日、私のモニターは動いていませんでした。モニターを再稼働させたのは10月31日で、トラフィックの検出器はこのフラッドの後に加わりました。¹⁹ 10月30日のブロックは、受信箱を読んだ人間によるものでした。

10月30日：1つのアドレスからの76,429件のリクエスト、1分ごと。私が手作業でアドレスをブロックするまで、エッジはほとんど何も拒否しませんでした。¹³¹⁰

3. 2回目のフラッド：11月2日、私のモニターがブロック

2つ目のアドレスは、オランダのホスティング事業者NovoServe B.V.のものです。⁴⁰ このアドレスは07:49 UTC（11月1日の太平洋標準時23:49）に2件のGETを送り、その後11.1時間何も送りませんでした。本格的なスキャンは18:56 UTCの分から19:17の分まで（10:56から11:17 PST）続きました。1分単位のバケット22個で10,907件のリクエスト、早朝の2件のGETを含めると10,909件です。4つの独立したクエリがこの合計で一致しています。¹⁴

同じツールのように見えました。10月30日のアドレスと同じWindows用Chrome 141のユーザーエージェント文字列を9,725件のリクエストで使い、同じGooglebotの文字列を942件で使い、同じインジェクションのファミリーを送り、同じ2つのゾーンにだけ触れて、kiradex.appには368件のGETを送っていました。⁴¹⁴²¹⁴ 2つの国の2つのネットワークにある2つのアドレスでは、誰がそれを動かしたかについて何も証明できないので、「見えた」にとどめておきます。

両方のタイムゾーンでのタイムライン

私のモニターの8分間

私のモニターは、スキャンの最初の1分から7.9分後に最初の検出結果を出し、ブロックはその8.0分後、つまり最初のファイアウォールイベントから6.8分後に有効になりました。¹⁹⁴ それまでに、ブロック前の数分間で26件の送信が出ており、最後の5件はブロックの分そのものに入っていました。1分ごとのデータでは、この5件をブロックの秒より前か後かに置くことはできません。それ以降の分には1件もありません。² 8分はブロックとしては速く、受信箱にとっては遅い時間です。

10:57:00 PSTに始まった実行は、スキャンを約1分間だけ視野に入れており、その時間枠の中でこのアドレスは29件から666件のあいだのリクエストを送っていました。上の数字は18:57の1分間をまるごと数えたもので、時間枠が見たのはそのうち22秒だけです。検出器は何の検出結果も記録しませんでした。¹⁹ 11:02:46 PSTの次の実行がフラッドを見つけてブロックし、その実行は、最初の実行がなぜ見逃しえたのかも示しています。その時間枠はCloudflareに問い合わせた瞬間に終わっており、最新のイベントはまだ届いていませんでした。実行のログにはこのアドレスからのリクエストが1,914件と記録されていますが、11月3日に完全なデータで同じ5分間の時間枠を再生すると2,143件になります。この再生はコマンドと完全な出力とともに保存してあり、その件数は台帳の補遺の行になっています。¹⁹⁴³ 再生では、ライブの実行が一度も出さなかったフォームフラッドの検出結果も出ました。39件の投稿（うち23件が拒否）による高重大度のもので、メールやブロックではなく、日次ダイジェストの1行になったはずのものです。⁴³ 私が再生したのは2回目の実行の時間枠で、1回目のものではありません。したがって10:57 PSTの実行についても同じ遅れが原因である可能性は高いものの、測定したわけではありません。同じ日に、モニターの時間枠を、各実行の90秒前に終わり、前回の時間枠が終わったところから始まるように変更しました。⁴³ このアドレスに対して検出結果は全部で6件発動し、私のモニターはそのすべてをメールで知らせる代わりに日次ダイジェストに畳み込みました。そのアドレスがすでにモニターのブロック台帳に載っていたからです。¹⁹ モニターがどうアラートを出すべきか、そしてモニター側から見たこのスキャナーについては、アラート疲れ：セキュリティモニターから1日82通のメールという別の記事のテーマです。この記事にとって大事なのは、ブロックは反応であり、その反応は31件の送信のうち少なくとも26件より後に来た、ということです。

フォーム、ステータス別

このアドレスはフォームに500回投稿しました。²

合計は、送信31件、アプリのリミッターによる拒否31件、エッジでの拒否438件で、エッジでの拒否はすべてブロックの分かそれ以降です。つまり、アプリに届いた投稿は62件です。² 送信の1件1件が、スキャナーが有効なCSRFトークンを持っていたことを証明します。ハンドラーは送信の前にトークンを確認するからです。429はどちらとも証明しません。リミッターは、ハンドラーがトークンを読む前に投稿を拒否するからです。²⁴¹⁶ Cloudflareがそれらの429についてオリジンのステータスを記録している範囲では、それはオリジンのもの、つまりアプリのリミッターのもので、このアドレスについてレート制限のファイアウォールイベントは1件もありません。³⁷⁴

スキャンの残り

結果別に見ると、11月2日のスキャンの内訳は次のとおりです。¹⁴

エッジの72.7%は大半がブロックによるものです。ブロックの分より前のリクエストが2,986件、後が7,445件で、サイトは後者を1件も配信していません。¹⁴ この日のパスのクエリは完全でした。異なるパスは2,173個で、そのうち542個のパスへの778件のリクエストがSQLインジェクションのペイロードを含んでいました。⁴⁴ ユーザーエージェントのクエリも完全で、異なる文字列は73個です。普通のChromeの文字列とGooglebotの名乗りのほかに、スキャナーは149件のリクエストで54種類のSQLペイロードを、78件で3種類の引用符を壊す文字列を送り、12個のマーカートークンをそれぞれ1回ずつ送っていました。⁴¹

いくつかの文字列は、スキャナーが何を尋ねていたかを示すので、見ておく価値があります。(select 198766*667891 from DUAL)は、テーブルのないselectの中の算術式です。PortSwiggerのチートシートが示すとおり、FROM dualはそのためのOracleの構文です。³³ if(now()=sysdate(),sleep(15),0)は、同じチートシートにある条件付きの時間遅延と同じIF(condition, SLEEP(n), x)の形をしています。³³ @@qkLpPは、チートシートがMicrosoftとMySQL向けにSELECT @@versionで使う@@の接頭辞に5文字が続いたもので、スキャナーはこれに似たものを1ダース送っていました。³³⁴¹ OWASPのテストガイドは、これらの文字列が使う2つの技法を名指ししています。「forces the database to generate an error」（データベースにエラーを生成させる）エラーベースのインジェクションと、「use database commands (e.g. sleep) to delay answers in conditional queries.」（データベースのコマンド（例：sleep）を使って条件付きクエリの応答を遅らせる）時間遅延です。⁴⁵ 私が取得したページのどれも、これらの文字列そのものを記載してはいないので、特定のツールに帰属させず、記述するだけにとどめます。

11月2日：1つのアドレスからの10,907件のリクエスト、1分ごと。私のモニターの2回の実行と、モニターが11:04:01 PSTに置いたブロックを示しています。¹⁴¹⁹

4. 5つの層と、それぞれが見分けられたもの

これらのボットと私の受信箱のあいだには、5種類の制御がありました。それぞれについて、私は同じ問いを立てました。ボットと人間を見分けられたか、です。エッジのルールにある1つのマネージドチャレンジは訪問者にその問いを投げられますが、対象はユーザーエージェント文字列が一覧にあるリクエストだけで、スキャナーの文字列はそこにありませんでした。脅威スコアをキーにした2つ目のチャレンジは決して発動しえなかったので、すべての送信にその問いを投げるものは何もありませんでした。制御のうち2つは数を数え、1つは名前と一覧を照合し、1つはサイトが発行したトークンをクライアントが持っていることを証明し、1つは隠しフィールドを埋めるボットだけを捕らえます。以下、それぞれが何を確認し、何を止め、残りをなぜ通したのか、その正確な理由を見ていきます。

エッジのカスタムルール

何を確認するか。 このサイトでは、最初のカスタムルールが、アカウントレベルの一覧にあるアドレスすべてと、ASNで指定した7つのホスティングネットワークをブロックします。別のルールは、.php、/wp-、/.envのようなエクスプロイトのパスの部分文字列をブロックします。さらに2つが、お問い合わせフォームと管理用のパスにマネージドチャレンジを返します。1つは空のユーザーエージェント、またはcurl、wget、python-requests、httpx、scrapy、HeadlessChrome、PhantomJS、Seleniumを含むユーザーエージェントに対して、もう1つはCloudflareの高い脅威スコアに対してです。スタジオのサイトにも同じ種類のルールがあり、2つのチャレンジはサイト全体に適用され、APIのパスに対するブロックはお問い合わせフォームを除外しています。⁹ 脅威スコアのチャレンジは、両サイトに1つずつ、死んだルールでした。Cloudflareのフィールドリファレンスによれば、このスコアはかつて0から100の範囲でしたが、「Now, the threat score is always 0 (zero).」（現在、脅威スコアは常に0（ゼロ）である）とあります。高いスコアを求めるルールは何にも一致しません。私はそれを読んだ11月3日に両方を無効にしました。ユーザーエージェントのチャレンジは残しています。¹¹⁴⁶ CloudflareのFreeプランでは5つのカスタムルールが使え、それらは「work as customized web application firewall (WAF) rules that you can use to perform actions like Block or Managed Challenge on incoming requests.」（受信リクエストに対してBlockやManaged Challengeのようなアクションを実行するのに使える、カスタマイズされたWebアプリケーションファイアウォール（WAF）ルールとして機能する）ものです。⁴⁷

何を止めたか。 エクスプロイトのパスは、両日とも最初の1分から止めました。¹⁰⁴ 10月30日には、フォーム投稿を1件も止めていません。¹¹⁰ 11月2日には、私のモニターのブロック後の438件のフォーム投稿を止めました。² スタジオのサイトでは、フォーム投稿を1件も止めていません。8日間で、ファイアウォールはフォームへのPOSTについて1件のイベントも記録しませんでした。⁷

なぜ残りを通したか。 どのルールも、リクエストが何者であるかを見ていないからです。一覧のルールがアドレスに一致するのは、何かがそれを一覧に載せた後だけです。10月30日は人間が、11月2日は私のモニターが載せました。⁹¹⁰¹⁹ ユーザーエージェントのチャレンジは文字列に一致するもので、2つのスキャナーはどちらもブラウザーの文字列を送っていました。初日は少なくとも69,322回、2日目は9,725回です。³²⁴¹ ユーザーエージェントのチャレンジは、自分の正体を名乗るツールには確かに効きます。10月30日の私自身のcurlテストは、24件のマネージドチャレンジを受けました。³⁹ 脅威スコアのチャレンジは誰に対しても発動しえず、ファイアウォールはどちらのアドレスについても、フォームに対するチャレンジを1件も記録していません。¹¹¹⁰⁴ Torの出口ノードや、名指しした7つのASN以外のホスティングネットワークは、どの一覧にも載っていません。

エッジのルールは、既知のアドレス、既知のネットワーク、正直なツールをそれ以外から見分けられます。そのチャレンジが人間がいるかを問うのは、その式が選んだリクエストに対してだけです。スキャナーが送るブラウザーの文字列を、ブラウザーから見分けることはできません。

エッジのレート制限

何を確認するか。 ルールの文面は短いものです。⁹

(http.request.method eq "POST" and http.request.uri.path in {"/api/contact" "/paint/share"})

一致するリクエストをCloudflareのデータセンターとクライアントのアドレスごとに数え、10秒あたり3件まで許し、10秒間ブロックします。均等にならせば、その上限はデータセンターごと、アドレスごとに1分あたり18件に名目上相当します。ルール自体は10秒の期間で数えています。⁹¹⁶ Freeプランでは、期間、タイムアウト、カウントのキーが固定されており、ゾーンにはこの種のルールが1つだけ与えられます。10秒のカウント期間、10秒の緩和タイムアウト、IPによるカウントです。⁴⁸ データセンターも任意ではありません。Cloudflareのドキュメントは「Every rate limiting rule includes the Cloudflare data center ID (cf.colo.id) as a mandatory characteristic」（すべてのレート制限ルールは、CloudflareのデータセンターID（cf.colo.id）を必須の特性として含む）と述べ、「Counters are not shared across data centers, with the exception of data centers associated with the same geographical location.」（同じ地理的位置に関連付けられたデータセンターを除き、カウンターはデータセンター間で共有されない）としています。⁶

何を止めたか。 どちらの日も、スキャナーのリクエストは1件も止めていません。インシデントの時間帯にこのルールが出したイベントは、私自身のテストの3件だけです。¹⁰⁴³⁹ スタジオのサイトにも独自のサイト全体のレート制限ルールがあり、Cloudflareが検証済みボットとして挙げるクライアントからのものを除くすべてのリクエストを同じ方法で数えています。このルールは、ドリップ（少量ずつ続く投稿）のフォーム投稿を1件も拒否しませんでした。8日間で、ファイアウォールはフォームへの投稿について1件のイベントも記録していません。このルールはアドレスがサイトに送るそうしたリクエストすべてを数え、私のデータはフォーム投稿しか数えていないので、カウンターにどれだけ余裕が残っていたかは測れません。⁹⁷

なぜ残りを通したか。 10月30日には、ルールは18:49:53 UTCまで存在しませんでした。手作業のブロックの最初のイベントと同じ秒で、アプリに最後のフォーム投稿が届いてから約12分後です。⁹¹ そのスキャナーの1,065件の投稿はすべて1つのデータセンター、パリを経由していたので、ルールがあれば、それらに対して1つのカウンターを保持していたはずです。⁵ 11月2日にはルールが存在しており、スキャナーのフォーム投稿は18:56から19:05:00 UTCまでに2つのデータセンターを経由して届きました。アムステルダムが44件、ロンドンが41件です。最も多い1分間である19:02には、ロンドンが18件、アムステルダムが14件を運びました。⁵ 1分間に18件はルールの上限に名目上相当しますが、私のデータは到着時刻ではなく1分ごとの合計なので、1つのデータセンターのいずれかの10秒間に3件を超えたかどうかは示せません。Cloudflareは精度についてはっきり述べています。「Rate limiting rules are not designed to allow a precise number of requests to reach your origin server. There may be a delay of up to a few seconds between detecting a request and updating rate counters.」（レート制限ルールは、正確な数のリクエストをオリジンサーバーに到達させるようには設計されていない。リクエストを検出してからレートカウンターを更新するまでに、最大で数秒の遅延がありうる）。⁴⁸ アプリに届いた最初の投稿から最後の投稿までの7分間で、スキャナーは1分あたり平均8.86件でした。² 当日の私のメモはそれを「about nine a minute」（1分あたり約9件）と呼んで、そこで止まっていました。データセンター間の分割こそ、メモが見落とした部分です。²³

ルールがそもそも機能することを証明したかったので、11月3日の朝、自分のマシンからプローブしました。06:36:49 PSTに、CSRFトークンなしで10件のPOSTを0.4秒間隔で送りました。4件は必須項目の欠落でFastAPIが拒否して422が返り、続く6件は429が返りました。06:38:03 PSTには、すべての項目をそろえて8件を送りました。3件はオリジンのCSRF拒否である403が返り、続く5件はCloudflareから「error code: 1015」という本文とともに429が返りました。その数分間に、ファイアウォールはフォームについて11件のイベントを記録し、そのすべてがレート制限ルールによるブロックでした。¹⁸ ルールは発動し、Cloudflareはそれを記録します。11月2日についての私の読みは仮説です。2つのカウンターに分かれ、それぞれで名目上の上限近くで走っていたため、スキャナーはどちらも作動させなかった、というものです。1分ごとの合計に合う最も有力な説明ではあっても、実証ではありません。合計からは、各分の中で投稿がどう間隔を空けていたかはわからず、Cloudflareも、カウンターの更新中に超過したリクエストが通りうることを認めています。⁵⁴⁸

レート制限は、1つのデータセンターの1つのアドレスについて、速いか遅いかを見分けられます。誰が送っているかは見分けられません。

CSRFトークン

何を確認するか。 このサイトのフォームには、ページに埋め込まれた隠しトークンがあり、3つの部分から成ります。タイムスタンプ、ランダムな値、そして最初の2つに対するHMAC署名です。サーバーは、署名が一致し、タイムスタンプが1時間以内であればそれを受け入れます。¹⁵ スタジオのサイトのフォームには、CSRFトークンがありません。²⁵

何を止めたか。 10月30日に4件の投稿（すべて18:03の分）、11月2日には0件です。¹²

なぜ残りを通したか。 トークンがステートレスだからです。セッションにもCookieにもアドレスにも結び付いていないので、ページを取得したクライアントは誰でも有効なトークンを手に入れられますし、別のクライアントからトークンを渡されたクライアントも、有効期間中はそれを提示できます。2つのスキャナーはどちらも実際にサイトのページを取得していました。リクエストのログがそれを示しています。チェックが示すことはもっと狭く、両日のすべての送信が、私のサイトが発行した有効で期限内のトークンを持っていた、ということです。ハンドラーは送信の前にトークンを確認するからです。^1513142416 CSRFトークンは、別のサイトが訪問者のブラウザーに私のフォームを送信させるのを止めるためにあります。自分でフォームを送信したいクライアントを止めることは、もともと意図されておらず、実際に止めませんでした。

同じチェックには2つ目の欠陥があり、それはボットではなく人間に降りかかるものでした。トークンが失敗すると、ハンドラーはHTMXのフォームが一度も表示しないJSONの403を返していたので、トークンの期限が切れた人は送信ボタンを押しても何も見えなかったはずです。¹² これは修正しましたが、最初の修正もうまく動きませんでした。その経緯は第6節で述べます。

有効なCSRFトークンが証明するのは、私のサイトが発行した期限内のトークンをクライアントが持っていたことです。誰がフォームに記入したのかも、そのクライアントがページを読み込んだことさえも、証明できません。

アプリのレートリミッター

何を確認するか。 このサイトのハンドラーはデコレーターの後ろにあり、そのデコレーターはクライアントのアドレスごと、時計の1分ごとのフォーム投稿をCloudflare KVで数え（メモリー内のフォールバック付き）、5件を超えると429で拒否します。¹⁷ スタジオのサイトには、匿名のクライアント向けにプロセスごとのメモリー内リミッターがあり、アドレスとクライアントの分類ごとに数えます。この分類は、リミッターがユーザーエージェントとアドレスから割り当てるクラスで、ヘルスチェックと静的ファイルを除くすべてのパスが対象です。²⁵

何を止めたか。 10月30日に830件、11月2日に31件の投稿です。スタジオのサイトでは0件です。¹²⁷

なぜ残りを通したか。 設計上、誰に対しても1分あたり5件を通すからです。しかも時間枠が時計の1分なので、分の境界をまたぐバーストには2回分の許容量が与えられます。¹⁷ そこまでは知っていました。件数をコードと照らし合わせて読むまで知らなかったのは、これが漏れるということで、しかもコードには漏れる経路が少なくとも3つあります。リミッターはKVからHTTPでカウンターを読み、上限と比較し、それからカウントに1を足した値を別のリクエストで書き込みます。そのため、どちらかが書き込む前に両方が読んだ2つの投稿は、両方とも通ります。インクリメントは書き込む前にカウンターをもう一度読み、その2回目の読み取りに失敗すると、書き込みがカウントを1に戻すので、その分はやり直しになります。そしてKVの読み取りが何も返さないか書き込みに失敗するたびに、判定は1つのプロセスのメモリーに保持したリストにフォールバックし、そのリストはほかのプロセスとは共有されません。¹⁷

件数が漏れを示しています。10月30日には、8つの分で5件を超える送信があり、18:06の分には18件ありました。¹ 1分5件の正確なリミッターなら、スキャナーが投稿した分を通して最大54件の送信しか許さなかったはずですが、101件が出ていき、上限を47件超えました。11月2日には19:02と19:03の分がそれぞれ9件と10件を通しました。正確なリミッターなら、それが見た62件の投稿のうち最大22件しか許さなかったはずですが、31件が出ていき、上限を9件超えました。³ どの経路が漏れたのかは、件数からはわかりません。私の読みでは、どちらかが書き込む前に複数の投稿が同じカウントを読んだか、負荷の下でKVの呼び出しが失敗してカウントがリセットされたり判定がプロセスごとのリストに渡ったりしたか、あるいはそれらの組み合わせです。手元のログはアプリが返したステータスを記録しているだけで、どの経路が判定したかは記録していないので、経路を区別できません。¹⁷³ 対処法はどの経路でも同じで、1行の変更では済みません。アトミックなインクリメントを持つカウンターストアです。KVの読み取りの後に別の書き込みを行う方式では、それは得られません。この漏れは私のバグです。同時にそれは、この記事の主張を、狙ってもできなかったほど鋭くしてくれます。5件と言いながら18件を通す制御が、誰が私に書き込めるかを決めるものになるはずは、最初からなかったのです。

スタジオのサイトでは、アプリのリミッターは観測されたフォーム投稿を1件も拒否せず、最も多く送ったアドレスでも1時間に13件でした。そのカウンターは、同じクライアントの分類のもとでアドレスがほかのすべてのパスに送るリクエストも取り込み、私のデータはフォーム投稿しか対象にしていないので、件数からカウンターにどれだけ余裕があったかは測れません。⁷²⁵

レートリミッターは、リクエストが順番に来るなら5件と6件を見分けられます。どんな件数でも、人間とスクリプトは見分けられません。

ハニーポット

何を確認するか。 スタジオのサイトのフォームには、人間には決して見えないwebsiteという名前のテキスト入力があります。tabindex="-1"とaria-hiddenが付いているので、キーボードもスクリーンリーダーもそこに止まりません。それが何かを入れて戻ってくると、ハンドラーは人間が見るのと同じ成功メッセージで応答し、何も保存もメール送信もしません。²⁵ この分岐は、私が6月5日にフォームを作ったときからハンドラーにあります。²⁵ このサイトのフォームにはハニーポットがありません。²⁴

Ned Batchelderは2007年にこの技法を説明しています。「These fields are called honeypots and are validated when the form data is posted. If they contain any text, then the submitter must be a bot」（これらのフィールドはハニーポットと呼ばれ、フォームのデータが投稿されたときに検証される。何かテキストが入っていれば、送信者はボットに違いない）。⁴⁹ それが機能する理由として彼が挙げるのは、フォームを埋めるボットが「cannot distinguish invisible fields from visible ones.」（見えないフィールドと見えるフィールドを区別できない）ことです。⁴⁹

何を止めたか。 8日間の52件中42件、80.8%の投稿です。到着した時間帯で見るとTorの出口ノードからの投稿すべてを含み、時間帯とメッセージのパターンで見ると、SQLスパイダーを自称するものの1回のバーストからの13件すべても含みます。⁷²⁰

なぜ残りを通したか。 見えるフィールドだけを埋めるボットはwebsiteに一度も触れません。そして投稿が保存され、つまり私の受信箱に届きえた送り手は、それを空のままにしていました。⁸²⁵ 彼らが意図して見えるフィールドを選んだというのは私の読みで、ハンドラーが記録しているのは隠しフィールドが空で戻ってきたということだけです。Batchelderはそれを予見していました。「In theory, it is possible for a spambot to defeat any of these measures. But in practice, bots are very stupid」（理論上、スパムボットはこれらの対策のどれでも破ることができる。しかし実際には、ボットはとても愚かだ）。⁴⁹ ほかより愚かでないボットもいて、リード獲得を売り込むものは中でも最も愚かでないものです。

ハニーポットが証明するのは、人間には見えないフィールドをクライアントが埋めたということだけです。空のハニーポットは何も証明しません。

それぞれのストリームがどこまで進んだか：このサイトへの2つのスキャナーの投稿と、スタジオのサイトへの8日間のドリップ。¹²⁷⁸

5つに共通していたこと

5つの結びの文を並べて読むと、隙間ははっきりします。レート制限はアドレスごとの量を抑えます。CSRFトークンは、サイトが発行したトークンをクライアントが持っていたことを証明します。ハニーポットは、クライアントが隠しフィールドを埋めたことを証明します。エッジのルールは名前と一覧を知っています。そして、向こう側に人間がいるかを問えるもの、つまりユーザーエージェントのチャレンジは、ユーザーエージェント文字列が一覧にあるリクエストにしか問いません。その隣の脅威スコアのチャレンジは決して発動しえませんでした。どちらのスキャナーも一致しなかったので、すべての送信に問いを投げるものは何もなく、スキャナーはブラウザーにできないことを何もしていませんでした。ページを取得し、そのトークンを保持し、制限が一部を通す速さで投稿しただけです。OWASPのクレデンシャルスタッフィングに関するガイダンスは、別のフォームについて同じ点を指摘し、「not rely on a single predictable volume limit」（単一の予測可能な量の制限に頼らない）防御を勧めています。⁵⁰

5. スタジオのサイトへのドリップ

スタジオのサイトのフォームには、フラッドは一度も来ませんでした。来たのはドリップ、つまり少量ずつ続く投稿で、これはまったく別の生き物です。ここでの時間枠は、8日間のクエリでフォーム投稿のあった最初の時間帯である10月26日17:00 UTCから、私がデータを保存した11月3日13:59:50 UTCまでです。最初と最後の日は一部だけです。⁷

投稿と保存された行

この時間枠で、フォームは52件のPOSTを受け、そのすべてに200で応答しました。同じ時間枠で、メッセージテーブルに増えた行は10行です。ハンドラーの中で200を返して何も保存しない経路はハニーポットの分岐だけなので、ハニーポットが残りの42件、つまり80.8%を捕らえたことになります。⁷⁸²⁵ UTCの日ごとでは次のとおりです。⁷⁸

10月30日の急増は、イギリスの1つのアドレスがMozilla/5.0 (compatible; SQLSpider/1.5)というユーザーエージェントで、1時間のうちに13件を投稿したものです。時間帯とメッセージのパターンで見ると、テーブルはそのどれも保存していません。その時間帯に保存された1行はリード獲得の売り込みで、同じ時間帯に投稿していたアメリカのアドレスのパターンです。⁷⁸²⁰

誰が送っていたか

Cloudflareは、TorネットワークからのリクエストにT1という特別な国コードを付けます。ヘッダーのリファレンスには「T1 - Used for clients using the Tor network」（T1：Torネットワークを使うクライアントに使用）とあり、IP Accessルールのページには「T1: Tor exit nodes (country name: Tor)」（T1：Torの出口ノード（国名：Tor））とあります。⁵¹⁵² このコードで見ると、52件の投稿のうち23件（44.2%）がTorから来ており、35個の異なるアドレスのうち23個（65.7%）がTorの出口ノードでした。⁷ 照合として、フォームに投稿したすべてのアドレスを、Tor Projectの一括出口リストと比べました。プロジェクトはこのリストを「a nearly real time authoritative source for Tor exits that allow contacting your server on port 80」（ポート80であなたのサーバーへの接続を許すTorの出口についての、ほぼリアルタイムの信頼できる情報源）と呼んでいます。CloudflareがT1とコード付けした23個のアドレスはすべて、11月3日に私が取得したリストに載っており、残りの12個はどれも載っていませんでした。⁵³⁵⁴ 2つの情報源は一致しています。ただしそのリストは11月3日の出口ノードなので、その日のコードを裏付けるだけで、各投稿が届いた日にどのアドレスが出口ノードだったかは証明しません。プロジェクトのCollecTorアーカイブは過去の出口リストを保持しており、イベント当日の所属を確定できますが、私はそれをクエリしていません。⁵⁵

この時間枠では、ほとんどのアドレスが1回だけ投稿していました。35個のうち32個（91.4%）で、Torの出口ノードはすべてその中にあります。⁷ 2回以上投稿した3つは、13件のSQLスパイダー、1時間に2件を送ったポーランドのアドレス、そして5件を送ったアメリカのアドレスです。最後のアドレスの5件の投稿は、この時間枠でテーブルが保存した5件のリード獲得の売り込みと同じ5つの時間帯に収まっており、しかも毎回ユーザーエージェントを変えていました。Linux上のChrome 135、続いてFirefox 128、137、138、そしてまた137です。⁷²⁰

ユーザーエージェントも同じ線で分かれました。Torの投稿のうち18件はAndroid端末を、5件はデスクトップのChromeを名乗り、23件中21件はChrome 81以前を名乗っていました。Tor以外の投稿は、それよりはるかに新しいデスクトップブラウザーを名乗っていました。125から135のデスクトップChromeが10件、128から138のFirefoxが6件、そしてスパイダー自身の名前での13件です。⁷

誰が保存されたか

2つのグループはハニーポットで出会いました。この時間枠で保存された行のうち、Torの投稿しかない時間帯にあるものは1つもなく、10行すべてがTor以外の投稿のある時間帯にあります。Torの投稿23件のうち22件は保存された行がまったくない時間帯にあり、23件目はアメリカのリード獲得のアドレスと時間帯を共有しています。²⁰ 時間帯で照合したのは、リクエストのログとメッセージテーブルに共通のリクエストIDがないからで、照合は推論です。到着した時間帯で見る限り、この時間枠のTorからの送信はすべてハニーポットにかかっていました。²⁰ 保存されたもの、つまり受信箱に届きえたものは、Tor以外のアドレスから、より新しいデスクトップブラウザーの文字列で送られ、ハニーポットを空のままにしていました。

数字は、フォームスパムの昔ながらのパターンに合っています。Batchelderの2007年の分類は、スパムの作り手を「Playback spambots, form-filling spambots, and humans.」（再生型スパムボット、フォーム記入型スパムボット、そして人間）に分けています。⁴⁹ Torのドリップは、すべてのフィールドを埋めてハニーポットに落ちるフォーム記入型のようにふるまいます。通り抜けた送り手は、キーボードの前にいる人間により近いもの、あるいは人間に見えるように作られたスクリプトのようにふるまいます。OWASPはこの活動をOAT-017、Spamming（スパム送信）に分類しています。「Malicious or questionable information addition to public or private content, or messages.」（公開または非公開のコンテンツやメッセージへの、悪意ある、または疑わしい情報の追加）。⁵⁶ OWASPは1つのことを対象外にもしています。「The mass abuse of broken form-to-email and form-to-SMS functions, to send messages to unintended recipients, is not included in this threat event」（壊れたフォームからメール、フォームからSMSへの機能を大量に悪用して意図しない受信者にメッセージを送ることは、この脅威イベントに含まれない）。⁵⁶ 私のフォームは私にしかメールを送らないので、含まれる側、つまりサイトの所有者に宛てたスパムであって、除外される側ではありません。

ドリップは、設計上レート制限も打ち負かします。OWASPのクレデンシャルスタッフィングに関するガイダンスは、リクエストを多数のアドレスに分散させる効果を名指ししています。「This may defeat both IP block-lists and rate limiting, as per IP request volume may remain relatively low」（IPごとのリクエスト量が比較的低いままでありうるため、これはIPブロックリストとレート制限の両方を打ち負かしうる）。⁵⁰ アドレスごとに1件の投稿は、量としてこれ以上ないほど低いものです。

保存されたメッセージの中身

メッセージテーブルは6月6日までさかのぼり、私が読んだ時点で108行ありました。最新のものは11月3日07:24 UTCに届いています。⁸ 私はそれらを固定のルールでパターン別に分けました。最初に一致したものを採用します。⁵⁷

いくつかは、もう少し詳しく見る価値があります。$50,000,000の9行は、1つの送り手の名前と9つの異なる送り手のアドレスで届き、どれも同じ見出しを少しずつ変えたものでした。⁸ 価格の質問は、テーブル全体で25の言語に現れます。アフリカーンス語、アルメニア語、バスク語、ベラルーシ語、ベンガル語、ブルガリア語、カタルーニャ語、クロアチア語、デンマーク語、英語、ジョージア語、ギリシャ語、ハンガリー語、アイスランド語、インドネシア語、アイルランド語、イタリア語、ラテン語、ラトビア語、リトアニア語、ルクセンブルク語、スペイン語、ベトナム語、ウェールズ語、ズールー語です。10月だけでも9つの言語で届きました。アルメニア語、バスク語、デンマーク語、インドネシア語、ラテン語、ラトビア語、リトアニア語、スペイン語、ベトナム語です。⁵⁷ 言語の判定のうち2つは私によるもので、微妙なところです。クロアチア語と読んだ文はボスニア語かもしれず、インドネシア語と読んだ文はマレー語かもしれません。⁵⁷ 誰かが、1言語ずつ、フレーズ集をお問い合わせフォームに通しているのです。

頻度は、ドリップのもう1つの特徴です。10月は32行を保存し、1日あたり1.03行、31日のうち21日に保存があり、1日に3行を超えた日はありませんでした。⁸ 1日1件では、アドレスごとのレート制限はどれも作動しません。

どれが受信箱に届いたか

フォームがスタジオの受信箱にメールを送るようになったのは、9月21日17:46:47 UTCからです。それ以来、43行を保存し、つまりメールで送っています。これは上限です。通知の呼び出しはベストエフォートで、デプロイ時刻も確認していないからです。その日付より前に保存された65行は、一度もメールで送られていません。²⁵⁸ 証拠の時間枠にある行は、すべてスパムです。⁵⁷

私自身のテストを除くと、テーブル全体でスパムでない行は1つだけです。9月14日、スタジオの製品の1つを使う顧客が、特定のエラーについて人間の言葉で書き送ってきましたが、そのメッセージは誰にも読まれないままテーブルに置かれていました。⁵⁷ その1週間後にフォームを受信箱へのメールにつないだとき、コミットメッセージはその理由を平易な言葉で書いています。「a paying customer’s message sat unread in D1 for a week」（有料顧客のメッセージがD1の中で1週間未読のままだった）。²⁵ このメッセージこそ通知機能が存在する理由であり、通知機能を切ってスパムを解決できない理由でもあります。送り手はここでは匿名にしておきます。要点は、本物の人間がフレーズ集と同じテーブルにいる、ということです。

6. ボットチェックとは何か、そして何を出荷したか

Cloudflare自身の言葉で見るTurnstile

CloudflareはTurnstileを自社の「smart CAPTCHA alternative」（スマートなCAPTCHAの代替）と呼び、「can be embedded into any website without sending traffic through Cloudflare and works without showing visitors a CAPTCHA.」（トラフィックをCloudflare経由にせずにどんなWebサイトにも埋め込め、訪問者にCAPTCHAを見せずに機能する）と述べています。²¹ 私の問いに答えるのは、その仕組みの部分です。概要ページは「First, we run a series of small non-interactive JavaScript challenges to gather signals about the visitor or browser environment,」（まず、訪問者やブラウザー環境についてのシグナルを集めるために、操作を必要としない小さなJavaScriptのチャレンジを一連の形で実行する）と述べ、「These challenges include proof-of-work (computational puzzles), proof-of-space, probing for web APIs, and various other challenges for detecting browser-quirks and human behavior.」（これらのチャレンジには、プルーフ・オブ・ワーク（計算パズル）、プルーフ・オブ・スペース、Web APIの探査、そしてブラウザーの癖や人間の行動を検出するためのさまざまなチャレンジが含まれる）と続けています。²¹ レート制限は、何件かを問います。CSRFトークンは、サイトが発行したトークンをクライアントが持っているかを問います。Turnstileは、向こう側にいるのがどんな種類のクライアントかを問います。私のユーザーエージェントのチャレンジもそれを問えましたが、対象はユーザーエージェント文字列が一覧にあるリクエストだけで、脅威スコアのチャレンジは決して発動しえませんでした。ここで重要な違いは、選択的に発動するチャレンジと、すべての送信に求められる検証との違いです。

ウィジェットには3つのモードがあります。私が使っているのはマネージドモードで、Cloudflareはこれを「Automatically chooses between non-interactive or checkbox challenge based on visitor risk level. No images or text to decipher.」（訪問者のリスクレベルに基づいて、操作不要のチャレンジかチェックボックスのチャレンジかを自動的に選ぶ。判読すべき画像や文字はない）と説明しています。⁵⁸ 平たく言えば、訪問者には短いチェックが見えるだけで、シグナルがそれ以上を求めない限り何もなく、求めた場合にはチェックを入れるボックスが表示されます。インビジブルモードはそれさえも隠しますが、Cloudflareはそれに条件を付けています。有効にしたサイトは、自身のプライバシーポリシーでCloudflareのTurnstile Privacy Addendumに言及しなければなりません。⁵⁸ Turnstileには独自の無料プランがあり、最大20個のウィジェット、チャレンジ数は無制限で、Cloudflareによれば「can be used independently without requiring other Cloudflare services.」（ほかのCloudflareのサービスを必要とせず独立して使える）ものです。⁵⁹

サーバー側の半分、本当に効くのはこちら

ウィジェットだけでは、フォームのためには何もしません。Cloudflareはサーバー側のガイドの冒頭でそう述べています。「You must call the Siteverify API to complete your Turnstile implementation. The client-side widget alone does not protect your forms.」（Turnstileの実装を完成させるには、Siteverify APIを呼び出さなければならない。クライアント側のウィジェットだけではフォームを保護しない）。さらに、もっと率直に「Tokens can be forged. An attacker can submit any string to your form endpoint without completing a challenge.」（トークンは偽造できる。攻撃者はチャレンジを完了せずに、フォームのエンドポイントに任意の文字列を送信できる）。⁶⁰ サーバーはシークレットキーとともにトークンをhttps://challenges.cloudflare.com/turnstile/v0/siteverifyにPOSTし、訪問者のIPアドレスをremoteipとして含めることもできます。⁶⁰

トークンの2つの性質が、その周りのコードの形を決めます。「Each token is valid for 300 seconds (5 minutes) after generation.」（各トークンは生成から300秒（5分）有効である）。そして「Tokens are single-use. Each token can only be validated once. A replayed token will be rejected with the timeout-or-duplicate error code.」（トークンは使い捨てである。各トークンは一度しか検証できない。再利用されたトークンはtimeout-or-duplicateのエラーコードで拒否される）。⁶⁰ トークンを1つ手に入れたスキャナーでも、それでフォームに1,065回投稿することはできません。Cloudflareはまた、トークンの長さを2,048文字までとし、サーバーに「Validate the action and hostname when specified.」（指定されている場合はactionとhostnameを検証せよ）と指示しています。⁶⁰ 同じページから1つ注意があります。期限切れのトークンについて、ある箇所ではtimeout-or-duplicateを挙げ、エラーの表ではinvalid-input-responseを「Token is invalid, malformed, or expired」（トークンが無効、不正な形式、または期限切れ）と説明しています。したがってサーバーは、1つのコードにロジックを結び付けるのではなく、どんな失敗も拒否として扱うべきです。⁶⁰

何を処理するか、Cloudflare自身の言葉で

Cloudflareは、Turnstileが個人データを使わないとは主張していませんし、私もそう主張するつもりはありません。Turnstileのプライバシー補遺はシグナルを名指ししています。「Cloudflare Turnstile processes a variety of client-side signals (“Signals”) such as client IP address, TLS Fingerprint, User-Agent Header and Sitekey and associated origin.」（Cloudflare Turnstileは、クライアントのIPアドレス、TLSフィンガープリント、User-Agentヘッダー、Sitekeyと関連するオリジンなど、さまざまなクライアント側のシグナル（「Signals」）を処理する）。目的もこう述べています。「The purpose of collecting these Signals is not to identify, profile or target any individuals but solely to detect and block bots.」（これらのSignalsを収集する目的は、個人を特定、プロファイリング、標的化することではなく、もっぱらボットを検出しブロックすることである）。そしてCloudflareがそれを製品の改善にも使うとしています。「Cloudflare is a data controller of Signals that we process to improve Turnstile’s bot detection capabilities.」（Cloudflareは、Turnstileのボット検出能力を改善するために処理するSignalsのデータ管理者である）。²² Cloudflareが手を付けないと述べているのは中身のほうです。「Turnstile does not access, store, or transmit user communications, form entries, or other page inputs.」（Turnstileは、ユーザーの通信、フォームの入力内容、その他のページの入力にアクセスせず、保存も送信もしない）。²¹ 製品ページは「Turnstile never harvests data for ad retargeting.」（Turnstileは広告のリターゲティングのためにデータを収集することは決してない）と付け加えています。⁶¹ 私の読みでは、Turnstileが見るのは私のエッジがすでにすべてのリクエストについて記録しているのと同じ種類の接続データで、人が私のフォームに打ち込む内容は決して見ません。

必要なCSP

TurnstileはCloudflareのチャレンジ用オリジンから読み込まれるので、Content Security Policyでそれを許可する必要があります。Cloudflareは2つのディレクティブを挙げています。「script-src: https://challenges.cloudflare.com」と「frame-src: https://challenges.cloudflare.com」です。⁶² 私の2つのゾーンは、どちらもCloudflareのレスポンスヘッダールールでポリシーを設定しています。このサイトではframeの一覧がすでにあり、そこにチャレンジ用オリジンを加えました。スタジオのサイトにはframe-srcがまったくなかったので、そのdefault-src 'self'がウィジェットのiframeをブロックしていたはずです。そこでframe-src 'self'とチャレンジ用オリジンを加え、コード内のアプリ自身のポリシーにも同じものを加えました。¹²

なぜフォームのPOSTそのものにマネージドチャレンジをかけないのか

手っ取り早い近道は、すでに私のゾーンにありました。フォームへのPOSTにマネージドチャレンジで応答するカスタムルールです。既存のルールはcurlとその仲間に対してそれを行っており、機能しています。curlを使って私にメッセージを送る人はいないからです。⁹³⁹ それをすべてのPOSTに広げれば、誰にとってもフォームが壊れていたでしょう。Cloudflareはその制約を直接文書化しています。「Challenge Pages interrupt the request flow by returning a full HTML page for the user’s browser to render and solve. This mechanism fails when the browser expects a non-HTML response, such as an AJAX or XHR (fetch) request.」（チャレンジページは、ユーザーのブラウザーが描画して解くための完全なHTMLページを返すことで、リクエストの流れを中断する。この仕組みは、AJAXやXHR（fetch）リクエストのように、ブラウザーがHTML以外のレスポンスを期待する場合には失敗する）。⁶³ このサイトのお問い合わせフォームはHTMXのフォームで、hx-postで投稿して応答をページに差し込むので、そのPOSTはまさにその種類のリクエストです。ドキュメントはHTMXを名指ししておらず、この結び付けは私の読みです。²⁴ チャレンジを受けたPOSTはHTMLのチャレンジページとして戻ってきます。Cloudflareはそれに「set to challenge」（challengeに設定された）cf-mitigatedヘッダーで印を付け、「Regardless of the requested resource-type, the content-type of a challenge will be text/html.」（要求されたリソースの種類にかかわらず、チャレンジのcontent-typeはtext/htmlになる）としています。⁶⁴ フォームは応答欄にチャレンジページを差し込むか、何も表示しないかのどちらかになるでしょう。

その場合についてのCloudflare自身の答えは、別の機能です。「To ensure your API calls are protected without breaking single-page applications (SPAs) or API integrations, Cloudflare recommends using Turnstile Pre-clearance.」（シングルページアプリケーション（SPA）やAPI連携を壊さずにAPI呼び出しを確実に保護するため、CloudflareはTurnstile Pre-clearanceの使用を推奨する）。⁶³ プリクリアランスでは、解かれたウィジェットがcf_clearance Cookieも発行し、このCookieは「enables visitors to bypass WAF Challenges on all subsequent requests on the zone, including API requests, based on the security clearance level set by the customer.」（顧客が設定したセキュリティクリアランスのレベルに基づいて、APIリクエストを含むゾーン上の以降のすべてのリクエストで、訪問者がWAFのチャレンジを回避できるようにする）ものです。Cookieはトークンの代わりにはなりません。Cloudflareは、それが「is issued to the visitor in addition to the default Turnstile token」（デフォルトのTurnstileトークンに加えて訪問者に発行される）と述べ、同じページでサーバーの確認を引き続き求めています。「You must call Siteverify to complete your Turnstile configuration.」（Turnstileの構成を完成させるにはSiteverifyを呼び出さなければならない）。⁶⁵ プリクリアランスが加えるのは、XHRの投稿が生き残れるエッジのチャレンジで、対象はチャレンジのレベル以上の有効なクリアランスをCookieに持つ訪問者です。私はデフォルトを使いました。フォームの中のウィジェットと、私自身のサーバーが確認するトークンです。

11月3日に出荷したもの

両方のサイトで、CloudflareのAPIを通じてマネージドモードのウィジェットを作り、それぞれのサイト自身のドメインに範囲を限定しました。各ウィジェットのシークレットは、同じプロセスの中でAPIの応答から私のMacのキーチェーンとホスティングサービスの変数へと渡し、コマンドラインにもファイルにも一度も載せていません。¹²

このサイト。 新しい検証器が、訪問者のアドレスとともにトークンをsiteverifyにPOSTします。トークンがない場合、2,048文字より長い場合、拒否された場合、通信に失敗した場合は、すべてfalseを返すので、シークレットが設定されている限り、フォームはフェイルクローズになります。ローカル開発やテストスイートのようにシークレットが設定されていない場合、フォームは以前と同じように動きます。¹² Cloudflareが受け入れたトークンは、このサイト自身のホスト名のいずれかで提供されたものでなければならず、Cloudflareがウィジェットのactionを返す場合は、それがフォーム自身のものでなければなりません。サーバー側のガイドが勧めるとおりです。ホスト名のない応答は拒否です。したがって、別のサイトや別のウィジェットで発行された有効なトークンは通りません。このチェックは同じ朝の2つ目の変更として入り、07:20 PSTからビルドしました。07:25 PSTにキャッシュをパージした後、ライブのページから取った有効なCSRFトークンを持ち、Turnstileのトークンを持たない投稿は、再び403で戻ってきました。これはデプロイ後もフォームがフェイルクローズのままであることを証明します。トークンのない投稿ではホスト名のチェックそのものを試せず、それはコードとテストに依拠しています。⁶⁶⁶⁰ 3つ目の変更までは、両方のウィジェットと両方の検証器がlocalhostも受け入れていました。sitekeyは公開されているので、誰かのlocalhostで私のsitekeyを使って発行されたトークンは、siteverifyもホスト名のチェックも同じように通っていたはずです。Cloudflareのテストのページはそれを勧めていません。「Cloudflare recommends that sitekeys used in production do not allow local domains」（Cloudflareは、本番で使うsitekeyがローカルドメインを許可しないことを推奨する）とあり、その中にlocalhostを挙げています。08:12 PSTに両方のウィジェットからlocalhostを外し、両方の検証器はデフォルトでサイトとそのwwwホストだけを受け入れるようになりました。こうしてチェックはこのサイト自身のホスト名だけを受け入れ、ほかは何も受け入れません。ローカル開発では設定でホスト名を指定します。その変更の後、両方のサイトは08:15と08:18（太平洋時間）に同じライブチェックに再び合格しました。ページ上のウィジェットと、403で拒否されるトークンのない投稿です。ホスト名のルールそのものを試せるライブチェックはありません。トークンがないかゴミのトークンなら、ホスト名が読まれる前に失敗するからです。そのルールは、ウィジェットの設定、コード、テストに依拠しています。⁴⁶⁶⁷ ハンドラーのチェックの順序は現在、CSRF、次にTurnstile、次に送信で、以前と同じアドレスごとのリミッターの後ろにあります。どちらの拒否もページ自身のエラー断片を403で返しますが、HTMXはデフォルトでは4xxの応答をページに差し込まないので、フォームには403を通すハンドラーが必要です。そのハンドラーの最初のバージョンは動きませんでした。私はそれをフォームに付けましたが、HTMXは応答を受け取る要素でイベントを発火させ、このページではその要素はフォームの兄弟要素なので、イベントはハンドラーに届かず、拒否された人にはやはり何も見えませんでした。この記事の草稿の2回目のレビューが、同梱のHTMXとテンプレートを突き合わせて読み、それを見つけました。修正はその朝の4つ目の変更で、リスナーをページのbodyに置き、応答欄に範囲を限定したもので、それが描画されることをテストで確認しています。そのデプロイ後の08:21 PSTに、ウィジェットのトークンをゴミの文字列に置き換えてPlaywrightのChromiumでフォームを動かしました。応答欄には「error: Verification failed. Reload the page and try again.」（エラー：検証に失敗しました。ページを再読み込みしてもう一度お試しください。）と表示され、何も送信されませんでした。siteverifyが、ハンドラーが送信に達する前にゴミのトークンを拒否するからです。⁶⁸ 古いCSRFの拒否、つまりHTMXが一度も表示しなかったJSONの403はなくなりました。フォームは、HTMXのリクエストのたびに、Cloudflareのリセット呼び出しが受け取る形でウィジェットのコンテナを指定して、自分のウィジェットをリセットします。そのため再試行には新しいトークンが付きます。各トークンは使い捨てで、寿命は300秒だからです。¹²⁶⁰⁶⁹ Cloudflareのクライアント側のガイドは、理由と呼び出しを示しています。「To reset the widget if the given widget timed out or expired, you can use the function:」（ウィジェットがタイムアウトまたは期限切れになった場合にリセットするには、次の関数を使える）turnstile.reset(widgetId);。⁶⁹ 私の最初のバージョンは引数なしでリセットを呼んでおり、それはガイドに記載されていません。4回目のレビューのラウンドがそれを見つけ、現在は両方のサイトで呼び出しがコンテナを指定しています。11月3日のブラウザーでのチェックでは、各フォームにゴミのトークンを送信して拒否を確認し、その後、隠し入力に新しいトークンが入ったことを確かめました。スタジオのサイトでは8秒以内、このサイトでは25秒以内で、こちらではウィジェットが先にチャレンジを再実行していました。¹² ウィジェットのdivとスクリプトは、サイトキーが設定されている場合にだけ描画されます。11個のテストが通ります。シークレットがなければ以前と同じように送信すること。シークレットがあれば、ハンドラーはどの送信よりも前にトークンのない場合を拒否し、拒否されたトークンも拒否し、受け入れられたトークンなら送信し、CSRFが引き続き先に実行されること。そして検証器がこのサイトのホスト名を受け入れ、別のホスト名、デフォルトでのlocalhost、別のaction、またはホスト名なしを拒否することです。¹²⁶⁶⁴⁶

スタジオのサイト。 ハニーポットは前に残しています。隠しフィールドが埋まっていれば、引き続き成功メッセージで応答して何も保存しないので、最も安上がりなボットのためにCloudflareへの呼び出しが発生することはありません。次にTurnstileが来て、トークンがない場合、拒否された場合、検証できない場合は、エラー断片とともに403を返します。その後にバリデーション、メッセージテーブルへの挿入、通知が続きます。¹² その検証器も同じ方法でホスト名（現在はサイト自身の2つのホスト名だけ）とactionを確認します。その変更は07:19 PSTにデプロイされ、07:22 PSTにはライブのページがウィジェットとサイトキーを持ち、トークンのない投稿とゴミのトークンの投稿は403で戻り、ハニーポットの投稿は引き続き200で応答しました。⁶⁶ デプロイの前に、Cloudflareが文書化しているテスト用キーに対してハンドラーをローカルで実行しました。常に合格するシークレットでは、トークンのない投稿は403で戻り、ダミーのトークンはTurnstileを通ってバリデーションに達しました。常に失敗するシークレットでは、どちらも403で戻りました。ハニーポットは200で応答しました。¹²⁶⁷ Cloudflareのテストのページは、ダミーのトークンが本番で通らない理由を述べています。「Production secret keys: Only accept real tokens, reject dummy tokens.」（本番のシークレットキー：本物のトークンだけを受け入れ、ダミーのトークンは拒否する）。⁶⁷

ライブチェック。 その朝早く、それぞれのサイト自身のデプロイが成功し、キャッシュをパージした後、06:35 PSTに、それぞれのトップページには1つのウィジェットのdiv、1つのTurnstileのscriptタグ、そしてサイトキーがあり、各ゾーンのライブのポリシーはframe-srcにチャレンジ用オリジンを挙げていました。このサイトのフォームへのゴミのCSRFトークンを持つ投稿は403で戻りましたが、それはCSRFチェックが拒否したもので、Turnstileについては何も証明しません。Turnstileのチェックそのものは06:43 PSTに試しました。ライブのページから取った有効なCSRFトークンを持ち、Turnstileのトークンを持たない投稿は、「error: Verification failed. Reload the page and try again.」というメッセージとともに403で戻り、同じ投稿にゴミのTurnstileトークンを付けても403で戻りました。つまり、シークレットはサービスに設定されており、チェックはCSRFの後に実行されています。スタジオのサイトでは、トークンのない投稿とゴミのトークンの投稿がどちらも403で戻り、ハニーポットの投稿は200で戻って、何も保存されずメールも送られませんでした。⁷⁰

ブラウザーでのチェック。 Playwrightで操作する本物のChromiumで、両方のページでウィジェットが描画され、Turnstileのスクリプトが読み込まれ、隠しのcf-turnstile-response入力は、両方のページで6秒以内に730文字のトークンを保持しました。⁷⁰ これは見かけほど多くを証明しません。Cloudflareのテストのページは「Automated testing suites (like Selenium, Cypress, or Playwright) are detected as bots by Turnstile」（自動テストスイート（Selenium、Cypress、Playwrightなど）はTurnstileによってボットとして検出される）と警告しており、トークンが通るかどうかを決めるのはsiteverifyだけです。⁶⁷ このチェックが証明するのは、ウィジェットが両方のポリシーの下で動き、自分のフィールドを埋めるということです。まだ行っていないのは、この記事の読者にとって最も重要な1つのテスト、つまり人間がフォームに記入して返信を受け取ることです。そのテストはメールを送るので、私が行うべきもので、まだ行っていません。

7. レート制限がまだ何のためにあるのか

Turnstileは、門としてのレート制限に取って代わりました。柵としてのレート制限に取って代わったわけではありません。ボットチェックは「誰が」に答えます。「何件か」には、まだ何かが答えなければなりません。空でない有効なサイズのトークンを持ってチェックに届く送信はすべて、今ではCloudflareのsiteverify APIへの呼び出し1回分のコストがかかり、通った投稿はすべて、引き続き送信1回分のコストがかかるからです。¹² Cloudflare自身のサーバー側のガイドは、siteverifyの呼び出しそのものについての推奨事項の中にレート制限を挙げています。「Rate limit to protect against validation flooding.」（検証のフラッドから守るためにレート制限をかける）。⁶⁰ 私の2つの制限は、どちらも残します。データセンターごと、アドレスごとに10秒あたり3件の投稿というエッジのルールと、アドレスごとに1分あたり5件の投稿というアプリのリミッターです。⁹¹⁷

どう数えるのかがわかった今、エッジのルールには正直な説明が必要です。Cloudflareはその設計を率直に述べています。「Cloudflare tracks request rates by maintaining separate counters for each unique combination of values in a rule’s characteristics,」（Cloudflareは、ルールの特性の値の一意な組み合わせごとに別々のカウンターを保持することでリクエストのレートを追跡する）、そして「Cloudflare does not support global rate limiting counters across the entire network.」（Cloudflareは、ネットワーク全体にわたるグローバルなレート制限カウンターをサポートしない）。⁶ 2つのデータセンターを経由して私のゾーンに届くアドレスは、2回分の許容量を得ます。そして11月2日のスキャナーの投稿は、実際に2つを経由して届きました。それが、ルールが沈黙していた理由についての私の最も有力な説明で、1分ごとの合計と矛盾しないものの、合計によって証明されてはいません。⁵ これに、ルールは「are not designed to allow a precise number of requests to reach your origin server」（正確な数のリクエストをオリジンサーバーに到達させるようには設計されていない）というCloudflareの精度についての但し書きを加えると、このルールは証明された上限ではなく、名目上の予算として説明するのが最も適切です。データセンターごと、アドレスごとに10秒あたり3件のフォーム投稿、名目上1分あたり18件に相当し、おおよそで執行されるものです。⁴⁸⁹ Freeプランでは、これが私に与えられる唯一のレート制限ルールでもあり、期間は10秒に固定され、カウントはIPだけで行われます。⁴⁸

私のように、レート制限そのものをチャレンジにしたくなった人には、Freeプランのある細部が重要です。Cloudflareのパラメーターのページによれば、Free、Pro、Businessプランでは、チャレンジのアクションを持つレート制限ルールは期間を保持せず常にスロットリングとして動き、「When visitors pass a challenge, their corresponding request counter is set to zero.」（訪問者がチャレンジに合格すると、対応するリクエストカウンターはゼロに設定される）とあります。⁷¹ フォームのXHRのPOSTに対するチャレンジは、第6節の理由でやはり失敗するでしょう。⁶³ そのため、エッジのルールはブロックのままにし、チャレンジはウィジェットの中に置きます。

アプリのリミッターには、その漏れが求める修正が必要です。2つの投稿が同じカウントを読むことのないアトミックなインクリメントを持つカウンターストアと、カウントをプロセスごとに分割しない失敗時の経路です。現在のコード、つまりKVの読み取りの後に別の書き込みを行い、プロセスごとのフォールバックを持つ方式は、そのどちらも提供しないので、これは1行のパッチではなくストアの変更になります。¹⁷³ 受信箱に届きうるすべての送信にTurnstileが条件として加わったので、漏れが通した投稿も、Cloudflareが受け入れるトークンを持っていなければなりません。そのため漏れのコストは量とお金になり、誰が投稿できるかの判断はもはやカウントには依存しません。リミッターは予算です。1回のフラッドで47件ずれる予算は悪い予算ですが、それはもともと門番ではなかったのです。

OWASPの認証に関するガイダンスは、同じ層の重ね方を独自の言葉で述べています。CAPTCHAを「as a defense-in-depth control to make brute-force attacks more time-consuming and expensive, rather than as a preventative.」（予防策としてではなく、総当たり攻撃により時間とコストがかかるようにする多層防御の制御として）扱っています。⁷² そしてクレデンシャルスタッフィングに関するガイダンスは、「Most tools used for these types of attacks will make direct POST requests to the server and read the responses, but will not download or execute JavaScript」（この種の攻撃に使われるツールの大半は、サーバーに直接POSTリクエストを送って応答を読むが、JavaScriptをダウンロードも実行もしない）と記しています。⁵⁰ 私の2つのスキャナーは実際にサイトのページを取得していました。それが、有効なCSRFトークンを持つに至った最もありそうな経路です。ウィジェットを実行せずにフォームに投稿するクライアントには、送るべきTurnstileのトークンがなく、両方のフォームは今ではトークンのない投稿を拒否します。このサイトでは、有効なCSRFトークンを持ちTurnstileのトークンを持たない投稿が403で戻り、スタジオのサイトでもトークンのない投稿が同じく403で戻りました。⁷⁰

チェックリスト

Cloudflareの背後にあるお問い合わせフォームについて、今の私ならこの順に行います。

1. フォームにボットチェックを置き、すべてのトークンをサーバーで検証する。 Cloudflare自身の言葉では「The client-side widget alone does not protect your forms.」（クライアント側のウィジェットだけではフォームを保護しない）。⁶⁰ 同じページが勧めるとおり、応答のホスト名とactionも確認し、ほかで発行されたトークンが通らないようにします。また、本番のsitekeyにはローカルドメインを含めないでください。「Cloudflare recommends that sitekeys used in production do not allow local domains」（Cloudflareは、本番で使うsitekeyがローカルドメインを許可しないことを推奨する）からです。⁶⁰⁶⁶⁶⁷
2. フェイルクローズにする。 トークンがない、大きすぎる、拒否された、検証できない場合は拒否です。「Tokens can be forged.」（トークンは偽造できる）からです。⁶⁰¹²
3. 送信のたびにウィジェットをリセットする。 トークンは使い捨てで有効期間は300秒なので、リセットなしの再試行は、使用済みのトークンでの再試行になります。⁶⁰⁶⁹
4. チャレンジ用オリジンを両方のCSPディレクティブで許可する。 Cloudflareはhttps://challenges.cloudflare.comについてscript-srcとframe-srcを求めており、default-src 'self'だけのポリシーはiframeをブロックします。⁶²¹²
5. XHRやfetchで投稿するフォームにマネージドチャレンジをかけない。 Cloudflareによれば、チャレンジページは「fails when the browser expects a non-HTML response」（ブラウザーがHTML以外のレスポンスを期待する場合に失敗する）もので、HTMXの投稿はその種類のリクエストです。⁶³
6. 人間に見えるエラーを返す。 私のCSRFの拒否はHTMXのフォームが一度も表示しないJSONの403だったので、トークンの期限が切れた人は送信ボタンを押しても何も見えなかったはずです。また最初の修正はフォームでイベントを待ち受けていましたが、HTMXは差し込みのイベントを応答のターゲット、つまりフォームの兄弟要素で発火させます。拒否はブラウザーで試してください。¹²⁶⁸
7. ハニーポットをボットチェックの前に置き続ける。 私のスタジオのサイトでは、隠し入力1つとif1つのコストで、52件中42件の投稿を捕らえました。⁷²⁵
8. レート制限は残し、門ではなくコストの上限として設定する。 Cloudflareはデータセンターごと、アドレスごとに数え、11月2日のスキャナーは2つを経由して届きました。それが一度も発動しなかった最もありそうな理由ですが、1分ごとの合計でそれを証明することはできません。⁶⁵
9. アプリのリミッターを、アトミックにインクリメントするストアで支える。 私のリミッターは、カウントを読んで別のリクエストで書き戻し、2回目の読み取りに失敗するとカウントを1に戻し、KVが失敗すると1つのプロセスのメモリーにフォールバックし、自身の上限を47件と9件超える送信を通しました。どの経路が漏れたのかは、ログからはわかりません。¹⁷³
10. スキャナーを止めるのにユーザーエージェントのルールを信頼しない。 2つのスキャナーはどちらも普通のChromeの文字列を送っており、10月30日は少なくとも69,322回、11月2日は9,725回でした。³²⁴¹
11. メールはフォームではなくメールサービスで数える。 私のハンドラーは失敗の経路でも200を返しますし、Resendのemail.sentイベントが意味するのは「the API request was successful」（APIリクエストが成功した）ということだけです。その後どうなったかは、取得したメールのlast_eventフィールドが示します。²⁴²⁸⁷³
12. 1か月以内に分析をクエリする。 Cloudflareの適応型データセットは「at least 31 days of data on every plan」（すべてのプランで少なくとも31日分のデータ）を保持します。²⁷
13. 時間枠が閉じてから数え直す。 10月30日のフラッドの数分後に書いた私のメモは、Cloudflareが最後の数分の取り込みを終えていなかったため、フォーム投稿を少なく数えていました。¹⁶
14. アドレスのブロックは後片付けとして扱う。 私のブロックは、10月30日には最初のフォーム投稿から約50分後、11月2日にはスキャン開始から8分後に入り、どちらの日もブロックの分より後に出た送信はありませんでした。10月30日はブロック前に101件、11月2日はブロック前に26件、ブロックの分の中に5件です。¹¹⁹²

何が変わりうるか

これらは予測ではなく条件です。それぞれ、何が起きなければならないか、そしてそのとき私が何をするかを示しています。

スキャナーがマネージドチャレンジを通り始めたら。 Turnstileのチェックはブラウザーの中で動き、自動化の痕跡を探します。それらを通るほど完全なブラウザーを大量に動かすツールにとって、ウィジェットは壁ではなく、もう1つのコストになるでしょう。兆候は、siteverifyが受け入れるトークンを持つフォームの送信が、User-Agentヘッダーにインジェクションの文字列も送るアドレスから来ることです。Batchelderは2007年に、ハニーポットについてこの正直な見通しを書いています。「If and when they do, we can switch back to CAPTCHAs.」（もしそうなったら、そのときはCAPTCHAに戻せばよい）。⁴⁹ 私の代替策も精神は同じで、より強いチャレンジです。それまでのあいだも、ハニーポットとレート制限は立ち続けています。

プリクリアランス付きのエッジのチェックを加えたら。 Cloudflareは、チャレンジページを描画できないリクエストにはTurnstileのプリクリアランスを推奨しており、cf_clearance Cookieは訪問者が「bypass WAF Challenges on all subsequent requests on the zone, including API requests」（APIリクエストを含むゾーン上の以降のすべてのリクエストでWAFのチャレンジを回避する）ことを可能にします。⁶⁵⁶³ それを採用すれば、エッジはチャレンジのレベル以上の有効なクリアランスをCookieに持つ訪問者についてHTMXを壊さずに、フォームのPOSTそのものにチャレンジをかけられます。CloudflareのCSPのページは、そのモードに1つの要件を加えています。「your connect-src directive must include ‘self’.」（connect-srcディレクティブに’self’を含めなければならない）。⁶² Cookieは「in addition to the default Turnstile token」（デフォルトのTurnstileトークンに加えて）発行され、siteverifyは引き続き必須なので、エッジのチャレンジは私のサーバーのチェックの前に置かれる2つ目のチェックであって、その代わりではありません。⁶⁵ 私はまだそれを行っておらず、この記事が説明しているのは稼働中のウィジェットとsiteverifyの設計です。

2つの時間枠についてResendのログをエクスポートしたら。 この記事のメールの件数はすべて上限です。フォームの200は、送信か、私のハンドラーが同じく200を返す失敗だからです。²⁴ Resendの取得エンドポイントは各メールのlast_event（deliveredなど）を返し、そのイベント一覧は「sent - The email was sent successfully.」（sent：メールは正常に送信された）と「delivered - Resend successfully delivered the email to the recipient’s mail server.」（delivered：Resendは受信者のメールサーバーにメールを正常に配信した）を区別しています。⁷³⁷⁴ そのエクスポートがあれば、101と31は正確な件数になり、減ることはあっても増えることはありません。

人間が手でスパムを送ってきたら。 Turnstileは、ブラウザーが、そしてときには人間がそこにいるかを問います。なぜ送るのかは問いません。お金をもらってお問い合わせフォームに売り込みを貼り付ける人はそれを通れますし、私のスタジオのサイトのリード獲得の送り手も、背後に人間がいるなら通れます。その場合の防御は昔ながらのものです。量に対するレート制限と、受信箱での私自身の判断です。

Torのドリップに日ごとの答えが必要になったら。 私が確認した出口リストは11月3日に取得したもので、Tor ProjectのCollecTorサービスは過去のリストを保持しています。⁵³⁵⁵ 8日分についてそれをクエリすれば、Torへの帰属は、Cloudflareのコードと11月3日のリストではなく、投稿が届いた日のリストに基づくことになります。Cloudflareはまた、すべてのプランでOnion Routingを提供しており、これはTorのユーザーにTorネットワークを通じて直接サービスを提供するものです。Cloudflareによれば、これを使うと「Human Tor users and bots can be distinguished by our Onion services, such that interactive challenges are only served to malicious bot traffic.」（人間のTorユーザーとボットを当社のOnionサービスで区別でき、操作を必要とするチャレンジは悪意あるボットのトラフィックにだけ提供される）とのことです。⁷⁵ 私はそれを有効にしておらず、有効にする前に、Turnstile導入後のスタジオのサイトのTorトラフィックを測りたいと考えています。

要点

お問い合わせフォームを運用しているなら：

• CSRFトークンとレート制限を組み合わせても、スキャナーはあなたに書き込めます。私の2つのスキャナーはどちらも有効なトークンを持っており、私のリミッターは101件と31件の送信を通しました。¹²
• ボットチェックのトークンはサーバーで検証し、フェイルクローズにし、リクエストのたびにウィジェットをリセットしてください。ウィジェットだけでは「does not protect your forms.」（フォームを保護しない）のです。⁶⁰
• リミッターは、1回に1リクエストずつではなく、負荷の下と失敗の下で試してください。読んでから書くカウンターにプロセスごとのフォールバックを組み合わせたものは、5件を許す設定の1分間に18件の送信を通しました。¹¹⁷
• ハニーポットは残してください。スタックの中で最も安上がりなフィルターで、私のスタジオのサイトでは8日間、ハンドラーがアドレスを確認したり、行を保存したり、メールを送ったりする前に、これらの送信の80.8%を捕らえました。⁷²⁵

サイトのエッジを運用しているなら：

• 自分のレート制限が何を数えているかを知ってください。Cloudflareでは、すべてのルールがデータセンターごとに数え、2つを経由して届くスキャナーは2つのカウンターを得ます。⁶⁵
• 自分のルールをプローブし、後でファイアウォールイベントを読んでください。私のプローブによる11件のファイアウォールイベントは、ルールがなぜ沈黙していたのかを1日考え続けるよりも多くのことを教えてくれました。¹⁸
• XHRやfetchのPOSTにチャレンジページでチャレンジをかけないでください。Cloudflareはそれが失敗することを文書化しており、その場合にはプリクリアランスを推奨しています。⁶³
• ユーザーエージェントのルールが捕らえるのは正直なツールだけだと考えてください。ここでのスキャナーはブラウザーの文字列を送り、私のcurlのテストはチャレンジを受けました。³²³⁹

受信箱を読むのがあなたなら：

• 受信箱が埋まったら、件名より先に送信元を確認してください。私のメールの流れのうち3つは1つの送信元アドレスを共有しており、それが最初の推測を誤らせた理由です。²³
• メールサービスのログが別のことを示すまでは、フォームの200をメールの件数ではなく上限として扱ってください。²⁴²⁸
• 通知機能を切る前に、保存されたメッセージを読んでください。かつて本物の顧客のメッセージが1週間未読のままだったことがあり、そのメッセージこそ、スタジオのフォームがそもそも私にメールを送る理由です。²⁵

よくある質問

Cloudflareを使っているのに、なぜお問い合わせフォームにスパムが届くのですか？

おそらく、フォームの前にあるどれも、すべての送信に対して人間が送ったのかを問うていないからです。Cloudflareのカスタムルールはアドレス、ネットワーク、パス、ユーザーエージェント文字列に一致し、レート制限はデータセンターごと、アドレスごとにリクエストを数えます。ブラウザーのユーザーエージェントを送り、先にページを読み込み、ほどほどの速さで投稿するスキャナーは、そのすべてを通り抜けます。私のサイトでは2つのスキャナーがまさにそうして101件と31件の送信を通し、私のスタジオのサイトのスパムは、私が測った8日間、大半がアドレスごとに1件の投稿で届きました。アドレスごとのカウントでは、これは捕らえられません。⁹⁶¹²⁷

レート制限はボットを止めますか？

レート制限は、1つのアドレスがどれだけ速く進めるかを抑えるもので、ボットと人間を見分けはしません。Cloudflare自身のドキュメントは、そのルールが「are not designed to allow a precise number of requests to reach your origin server」（正確な数のリクエストをオリジンサーバーに到達させるようには設計されていない）こと、そしてカウンターがデータセンター間で共有されないことを述べています。私のエッジのルールはどちらのスキャナーにも一度も発動せず、1分5件に設定したアプリのリミッターは1分間に18件を通しました。そのカウンターは読み取りの後に別の書き込みを行うもので、2回目の読み取りに失敗すると1にリセットされ、ストアが失敗するとプロセスごとのフォールバックが引き継ぎます。どの経路でも、余分な投稿が通りえます。^48641173

ハニーポットのフィールドで十分ですか？

隠しフィールドを埋めるボットには十分で、私のスタジオのサイトでは、それがこれらの送信の80.8%でした。8日間で52件中42件の投稿を捕らえ、到着した時間帯で見ると、そこにはTorの出口ノードからの投稿すべてが含まれていました。隠しフィールドを空のままにする送り手には何もできず、通した10件（保存され、つまり最大10通のメール）はまさにそうしていました。⁷²⁰ 2007年にこの技法を説明したNed Batchelderも、そう述べています。「In theory, it is possible for a spambot to defeat any of these measures.」（理論上、スパムボットはこれらの対策のどれでも破ることができる）。⁴⁹

TurnstileとCAPTCHAの違いは何ですか？

古典的なCAPTCHAは、訪問者にパズルを解かせます。Turnstileは「a series of small non-interactive JavaScript challenges to gather signals about the visitor or browser environment」（訪問者やブラウザー環境についてのシグナルを集めるための、操作を必要としない小さなJavaScriptのチャレンジの連続）を実行し、マネージドモードでは訪問者のリスクがそれを求めるときにだけチェックボックスを表示し、「No images or text to decipher.」（判読すべき画像や文字はない）とされています。²¹⁵⁸ Cloudflareは、自社のチャレンジが「CAPTCHA puzzles or visual tests like selecting objects or typing distorted characters.」（CAPTCHAのパズルや、物体を選んだり歪んだ文字を入力したりする視覚的なテスト）を使わないと述べています。⁷⁶ どちらの場合も、結果をサーバーで検証する必要があることに変わりはなく、Turnstileではそれがsiteverifyの呼び出しです。⁶⁰

なぜCSRF対策はスパムを止めないのですか？

正しく実装されたCSRF対策は、別のサイトが訪問者のブラウザーにあなたのフォームを送信させるのを止めるためのものです。私のトークンはそれより弱く、ステートレスで署名付き、有効期間は1時間で、セッションにもCookieにもアドレスにも結び付いていません。したがって証明するのは、私のサイトがその1時間以内に発行したトークンをクライアントが持っていることだけで、リクエストがどこから来たかではありません。どちらの種類も、ページを読み込んで自分でフォームを送信するクライアントは止めません。ページを読み込むことこそ、クライアントが有効なトークンを得る方法だからです。2つのスキャナーはどちらも有効なトークンを集めており、チェックが拒否したのは、2回のフラッドを通して彼らの投稿のうち4件でした。¹⁵¹²

ログでスキャナーと人間を見分けるにはどうすればよいですか？

フォームだけでなく、そのアドレスがしたことすべてを見てください。私の2つのスキャナーは何千ものパスをクロールし、パスとUser-AgentヘッダーにSQLインジェクションの文字列を入れ、大半のリクエストでChromeのユーザーエージェントを送り、一部ではCloudflareの検証済みボットのルールが受け入れなかったGooglebotの名乗りを送り、1分あたり数十から数百件のバーストでフォームに投稿していました。^31324441 sleep(15)やwaitfor delay '0:0:15'のような時間ベースのペイロードは、文書化されたプローブのファミリーに属します。³³⁷⁷ 人間は、実際に読んだページから1通のメッセージを送り、あなたのサーバーに眠るよう求めたりはしません。

Turnstileは個人データを収集しますか？

Cloudflareは、何も収集しないとは言っていません。Turnstileのプライバシー補遺は、処理するシグナルとして「such as client IP address, TLS Fingerprint, User-Agent Header and Sitekey and associated origin」（クライアントのIPアドレス、TLSフィンガープリント、User-Agentヘッダー、Sitekeyと関連するオリジンなど）を挙げ、目的は「solely to detect and block bots」（もっぱらボットを検出しブロックすること）だとし、Cloudflareがボット検出の改善のためにそれらのシグナルのデータ管理者であると述べています。概要ページは、Turnstileが「does not access, store, or transmit user communications, form entries, or other page inputs.」（ユーザーの通信、フォームの入力内容、その他のページの入力にアクセスせず、保存も送信もしない）としています。²²²¹ つまりTurnstileが見るのは接続データで、人が打ち込む内容ではありません。

このサイトの関連記事。 Claude Code の auto モードはセキュリティ境界ではないは、別の制御について同じ主張をしています。各アクションを判定する分類器は壁ではない、という主張です。Agents.txtはアクセス制御ではありませんは、ボットに方針を宣言することと、それを強制することのあいだに線を引いています。アラート疲れ：セキュリティモニターから1日82通のメールは、11月2日のスキャナーを私のモニターの側から扱っています。最初の検出結果から8秒後、スキャン開始から8分後のブロック、そしてそれについてのメールは0通です。寝る前に実行することは、別の種類の運用ルーティンで、15,000ページのステータス、応答時間、キャッシュを毎晩確認するものです。AIエージェントを無人で実行すると実際に何が壊れるのかは、監督なしのエージェントのセッション、つまり私のインフラを動かしている種類の自動化の失敗モードを分類しています。

出典

著者のデータについての注記：私自身のシステムから得た件数はすべて、2つのゾーンについてのCloudflareのGraphQL Analytics API（リクエストとファイアウォールイベントのデータセット）、スタジオのサイトのメッセージテーブル、私のモニターのログ、そして2つのフォームのコードから来ており、すべて2026年11月3日に保存し、スクリプトで台帳に変換したものです。時刻は、PDTまたはPSTと明記したもの以外はUTCです。その証拠に含まれるアドレス、ルールや一覧の識別子、キー、ファイルシステムのパスは、この記事には一切載せていません。