Cloudflare Turnstile 攻防設計：システム原理とコントロールプレーン

本文ほんぶんでは Turnstile の攻防設計こうぼうせっけいに焦点しょうてんを当あてる：

システム原理システムげんり：token の安全あんぜんセマンティクス、チャレンジ実行じっこうチェーン、リスクスコアリングの入力にゅうりょくと出力しゅつりょく
コントロールプレーン設計コントロールプレーンせっけい：異ことなる攻撃面こうげきめんにおいて、どの制約せいやくが必要ひつようで、どの制約せいやくが副作用ふくさようを招まねきやすいか

本文ほんぶんには、コマンドライン操作そうさやエンジニアリング実装手順エンジニアリングじっそうてじゅんは含ふくまない。

一いち、システム原理システムげんり

1.1 Turnstile は「能力のうりょくトークン」システムである

Turnstile の本質ほんしつは、短みじかいライフサイクルを持もち、一度いちどだけ消費しょうひされる能力のうりょくトークン（capability token）を発行はっこうすることにある。

発行側はっこうがわ：ブラウザ側がわでチャレンジ実行じっこうを完了かんりょうした後あとに token を取得しゅとくする
消費側しょうひがわ：業務ぎょうむサーバー側がわが Siteverify で token を検証けんしょうし、通過つうかさせるかどうかを決定けっていする

$ mermaid

flowchart LR
  A["浏览器端挑战执行"] --> B["token"]
  B --> C["业务服务端"]
  C --> D["Siteverify"]
  D --> E{"放行/拒绝"}

重要じゅうような意味いみ：

フロントエンドのどのような「通過つうか」状態じょうたいも、業務ぎょうむの通過条件つうかじょうけんではない
業務ぎょうむの通過条件つうかじょうけんは「token が正ただしく消費しょうひされたこと」である

1.2 Token の三みっつの安全あんぜんセマンティクス

token の安全あんぜんセマンティクスは、三みっつの制約せいやくとして抽象化ちゅうしょうかできる：

必かならずサーバー側がわで検証けんしょうする：フロントエンドのコールバックだけを根拠こんきょにすることは許可きょかしない
有効期間ゆうこうきかんを制限せいげんする：token が有効時間ゆうこうじかんウィンドウを超こえると失効しっこうする
一度いちどだけ消費しょうひする：同おなじ token の重複消費ちょうふくしょうひは失敗しっぱいすべきである

これら三みっつのセマンティクスは、それぞれ三みっつの一般的いっぱんてきな攻撃目標こうげきもくひょうを封ふうじ込こめている：

偽にせの通過つうか：サーバー側がわ検証けんしょうをバイパスする
遅延送信ちえんそうしん：有効時間ゆうこうじかんウィンドウをバイパスする
リプレイ/並行へいこう：一度いちどだけの消費しょうひをバイパスする

1.3 チャレンジ実行じっこうチェーンは「クロスオリジン実行クロスオリジンじっこうシステム」である

Turnstile の token 生成せいせいは複数ふくすうのコンポーネントの協調きょうちょうに依存いぞんし、さらにクロスオリジンのチェーンが主導的しゅどうてきな役割やくわりを持もつ：

api.js スクリプト
challenge iframe
challenge worker
クロスオリジンリソースリクエスト

$ mermaid

flowchart TD
  A["加载 api.js"] --> B["创建 iframe"]
  B --> C["执行 worker"]
  C --> D["收集信号 + 风险评估"]
  D --> E["签发 token"]

このチェーンのエンジニアリング上エンジニアリングじょうの意味いみ：

クロスオリジンスクリプト/iframe/worker のセマンティクスを書かき換かえる操作そうさは、token 生成せいせいの失敗しっぱいまたは品質低下ひんしつていかにつながりうる
token の失敗しっぱいは必かならずしも「識別しきべつされた」ことを意味いみせず、「チェーンが破壊はかいされた」可能性かのうせいもある

1.4 リスクスコアリング：入力にゅうりょくは「真偽しんぎ」ではなく「自己整合性じこせいごうせい」である

チャレンジ実行段階じっこうだんかいでは、環境かんきょうと行動こうどうの信号しんごうを収集しゅうしゅうし、リスクスコアを形成けいせいする。

信号入力しんごうにゅうりょく：環境かんきょうの一貫性いっかんせい（UA/UA-CH、言語げんご/タイムゾーン、レンダリング能力レンダリングのうりょく、能力露出のうりょくろしゅつ）
行動入力こうどうにゅうりょく：時系列分布じけいれつぶんぷ（分散ぶんさん、周期性しゅうきせい、同期性どうきせい）

リスクスコアリングの要点ようてんは「ある固定こていされたプロファイルに適合てきごうすること」ではなく、「同一どういつの身元みもとが複数ふくすうの表面ひょうめんで自己整合的じこせいごうてきかどうか」である。

1.5 反はんデバッグスクリプトは独立どくりつした攻撃面こうげきめんであり、フィンガープリント命中めいちゅうと同一どういつではない

高たかいリスク制御リスクせいぎょを行おこなうサイトでは、「能動防御のうどうぼうぎょスクリプト」（たとえば disable-devtool）がよく見みられる：

ページ起動後きどうごに開発者かいはつしゃツール、コンソールフック、デバッグ停止ていしの特徴とくちょうを検出けんしゅつする
命中後めいちゅうごに能動的のうどうてきな処置しょち（window.close / history.back / エラーページへの遷移せんい）を実行じっこうする

このチェーンの要点ようてん：

これは「反はんデバッグ実行面じっこうめん」であり、「フィンガープリントスコアリング面めん」の単純たんじゅんな部分集合ぶぶんしゅうごうではない
「ページが自動的じどうてきに閉とじる/自動的じどうてきに遷移せんいする」として現あらわれるが、根本原因こんぽんげんいんはランタイムの反はんデバッグ発火はっかである可能性かのうせいがある

エンジニアリング上エンジニアリングじょうは、これを「フィンガープリント問題もんだい」と階層分離かいそうぶんりして扱あつかう必要ひつようがある。そうしないと誤判定ごはんていしやすい。

1.6 スコープバインディング：hostname / action / cdata

サーバー側がわの検証時けんしょうじには、業務ぎょうむセマンティクスを結むすび付つけるためのフィールドが提供ていきょうされる：

hostname：token が許可きょかされるサイトスコープ
action：token が許可きょかされるアクションスコープ
cdata：token が許可きょかされるコンテキストスコープ

これらのフィールドの役割やくわりは「token が悪用あくようされうる範囲はんいを縮小しゅくしょうすること」であり、「通過率つうかりつを高たかめること」ではない。

$ mermaid

flowchart LR
  A["token"] --> B["hostname 作用域"]
  A --> C["action 作用域"]
  A --> D["cdata 作用域"]
  B --> E["降低站外盗用收益"]
  C --> F["降低动作错配收益"]
  D --> G["降低跨流程重放收益"]

1.7 Token 状態機械じょうたいきかい（能力のうりょくトークンの視点してん）

能力のうりょくトークンの視点してんから、token のライフサイクルは次つぎのように抽象化ちゅうしょうかできる：

$ mermaid

stateDiagram-v2
  [*] --> Issued: challenge ok
  Issued --> Consumed: siteverify ok
  Issued --> Expired: time window
  Issued --> Rejected: binding mismatch
  Issued --> Replayed: reused
  Replayed --> Rejected
  Expired --> Rejected
  Consumed --> [*]

設計目標せっけいもくひょうは、「不正ふせいなパス」を素早すばやく失敗しっぱいさせ、かつ失敗しっぱいの種類しゅるいをサーバー側がわのセマンティクスで区別くべつできるようにすることである。

1.8 攻撃木こうげきぎ（上位じょういレベル）

Turnstile の主おもな攻撃目標こうげきもくひょうは、次つぎのように抽象化ちゅうしょうかできる：

$ mermaid

flowchart TD
  A["绕过业务动作门禁"] --> B["伪造或跳过服务端验证"]
  A --> C["重放 token"]
  A --> D["扩大 token 作用域"]
  A --> E["破坏挑战执行以制造降级路径"]
  C --> C1["并发提交"]
  C --> C2["延迟提交"]
  D --> D1["Any Hostname"]
  D --> D2["action/cdata 缺失"]

この攻撃木こうげきぎが強調きょうちょうする設計上せっけいじょうの重点じゅうてん：

安全判断あんぜんはんだんは必かならずサーバー側がわで閉とじたループにする
token は必かならずスコープを縮小しゅくしょうし、セマンティクスに従したがって消費しょうひする

二に、コントロールプレーン設計コントロールプレーンせっけい（攻防こうぼうの視点してん）

2.1 コントロールプレーンの階層化かいそうか

Turnstile の防御線ぼうぎょせんは、四よんつのコントロールプレーンに分わけられる：

チャレンジ実行制御じっこうせいぎょ：スクリプト/iframe/worker のクロスオリジンチェーンの完全性かんぜんせいを保証ほしょうする
サーバー側がわ消費制御しょうひせいぎょ：token のセマンティクスが正ただしく消費しょうひされることを保証ほしょうする
スコープ制御スコープせいぎょ：hostname/action/cdata の利用可能範囲りようかのうはんいを縮小しゅくしょうする
摩擦制御まさつせいぎょ：clearance はチャレンジの摩擦まさつを下さげるために使つかう（安全判断あんぜんはんだんの根拠こんきょにはしない）

$ mermaid

flowchart LR
  A["挑战执行控制"] --> E["token 可生成"]
  A --> F["token 质量"]
  B["服务端消费控制"] --> G["安全决策闭环"]
  C["作用域控制"] --> H["滥用收益收缩"]
  D["摩擦控制"] --> I["挑战频率下降"]

2.2 チャレンジ実行制御じっこうせいぎょ：クロスオリジンセマンティクス保護ほごを優先ゆうせんする

チャレンジ実行じっこうチェーンは、クロスオリジン実行じっこうセマンティクスに非常ひじょうに敏感びんかんである。

原則げんそく：

クロスオリジンスクリプト/iframe/worker のセマンティクス改変かいへんを避さける
すべてのフィンガープリント修飾しゅうしょくは、まず「チャレンジ実行じっこうを破壊はかいしない」という強つよい制約せいやくを満みたさなければならない

この原則げんそくのエンジニアリング上エンジニアリングじょうの意味いみ：

「実行完全性じっこうかんぜんせい」は上流条件じょうりゅうじょうけんである
「信号修飾しんごうしゅうしょく」は下流最適化かりゅうさいてきかである

補足ほそく：反はんデバッグスクリプトは実行制御じっこうせいぎょの一部いちぶである。

ページに能動防御のうどうぼうぎょスクリプト（disable-devtool-auto 入口いりぐちなど）が含ふくまれる場合ばあい、「自動発火入口じどうはっかいりぐち」と「通常つうじょうの業務ぎょうむスクリプト」を分離ぶんりして扱あつかう必要ひつようがある
最小化さいしょうかすべき目標もくひょうは、その自動化処置じどうかしょちチェーンを遮断しゃだんし、チャレンジスクリプト/クロスオリジンコンポーネントへの誤傷ごしょうを避さけることである
処理境界しょりきょうかいは「高たかリスクな発火入口はっかいりぐちだけを抑制よくせいし、汎用はんよう DOM セマンティクスを書かき換かえない」ことにすべきである

2.3 サーバー側がわ消費制御しょうひせいぎょ：token を能力のうりょくとして消費しょうひする

サーバー側がわ消費制御しょうひせいぎょの設計上せっけいじょうの要点ようてんは、「通過条件つうかじょうけんの定義ていぎ」であり、「インターフェース呼よび出だしの詳細しょうさい」ではない。

通過条件つうかじょうけんは、三みっつの制約せいやくを反映はんえいすべきである：

真正性しんせいせい：success を検証けんしょうする
スコープ：hostname を検証けんしょうする
セマンティックバインディング：action/cdata を検証けんしょうする

さらに、token の二ふたつの安全あんぜんセマンティクスを徹底てっていしなければならない：

時効性じこうせい：期限切きげんぎれは拒否きょひする
単回性たんかいせい：リプレイは拒否きょひする

攻防こうぼうの視点してんでは、この層そうが解決かいけつするのは「バイパスとリプレイ」である。

2.4 スコープ制御スコープせいぎょ：Hostname Management と Any Hostname

Hostname 管理かんりは「サイト外がいでの盗用とうよう」という攻撃面こうげきめんを解決かいけつする。

Hostname Management を有効化ゆうこうかする：token が利用可能りようかのうなサイト範囲はんいを縮小しゅくしょうする
Any Hostname を有効化ゆうこうかする：token が利用可能りようかのうなサイト範囲はんいを拡大かくだいする

設計上せっけいじょうの結論けつろん：

Any Hostname は「より柔軟じゅうなん」なのではなく、「攻撃面こうげきめんを拡大かくだいする」ものであり、より強つよいサーバー側がわ制約せいやくで補償制御ほしょうせいぎょ（送信元そうしんもとドメインの許可リストきょかリスト + 業務ぎょうむバインディング）を行おこなう必要ひつようがある。

2.5 摩擦制御まさつせいぎょ：Pre-clearance と cf_clearance の境界きょうかい

Pre-clearance 通過後つうかごは clearance を生成せいせいでき、後続こうぞくの WAF チャレンジ連携れんけいに使つかわれる。

境界定義きょうかいていぎ：

clearance は体験層たいけんそうで使つかう（重複ちょうふくチャレンジの摩擦まさつを下さげる）
Siteverify は安全判断層あんぜんはんだんそうで使つかう（業務ぎょうむの通過根拠つうかこんきょ）

両者りょうしゃを混用こんようすると、「体験信号たいけんしんごうが安全信号あんぜんしんごうを代替だいたいする」という設計上せっけいじょうの欠陥けっかんを招まねく。

2.6 高対抗こうたいこうシナリオ：プロキシプールとデバイス関連付デバイスかんれんづけ

プロキシプールと分散型ぶんさんがたの悪用あくようシナリオでは、単一たんいつ IP 次元じげんの制約せいやくは失効しっこうしやすい。

設計方向せっけいほうこうは、より安定あんていした関連付かんれんづけ次元じげん（たとえばデバイスレベルの ephemeral id）を導入どうにゅうし、クラスタリングとしきい値戦略しきいちせんりゃくに使つかうことである。

この層そうは、プラットフォーム能力のうりょくと業務ぎょうむリスク制御せいぎょの境界きょうかいに属ぞくする：

プラットフォームは関連信号かんれんしんごうを提供ていきょうする
業務ぎょうむはアクション階層アクションかいそう、しきい値しきいち、処置戦略しょちせんりゃくを定義ていぎする

三さん、方案設計ほうあんせっけいの優先順位ゆうせんじゅんい

Turnstile の攻防設計こうぼうせっけいは、通常つうじょう次つぎの優先順位ゆうせんじゅんいで進すすめる：

サーバー側がわ消費しょうひセマンティクスの閉とじたループ（真正性しんせいせい + スコープ + バインディング + 単回性たんかいせい + 時効性じこうせい）
チャレンジ実行じっこうチェーンの完全性かんぜんせい（クロスオリジンセマンティクス保護ほご + 反はんデバッグ発火面はっかめんの治理ガバナンス）
信号しんごうの一貫性いっかんせい（フィールド間かんの矛盾むじゅんを減へらす）
行動時系列こうどうじけいれつ（機械的きかいてきな分布ぶんぷを下さげる）
体験最適化たいけんさいてきか（clearance などの摩擦制御まさつせいぎょ）

この順序じゅんじょの意味いみは、まず「正ただしい安全判断あんぜんはんだん」を定義ていぎし、その後あとに「チャレンジの摩擦まさつと通過率つうかりつの変動へんどう」を最適化さいてきかすることである。

公式参考こうしきさんこう（概念がいねんと設定せってい）

Widgets: https://developers.cloudflare.com/turnstile/concepts/widget/
Widget configurations: https://developers.cloudflare.com/turnstile/get-started/client-side-rendering/widget-configurations/
Server-side validation: https://developers.cloudflare.com/turnstile/get-started/server-side-validation/
CSP: https://developers.cloudflare.com/turnstile/reference/content-security-policy/
Hostname management: https://developers.cloudflare.com/turnstile/additional-configuration/hostname-management/
Any Hostname: https://developers.cloudflare.com/turnstile/additional-configuration/hostname-management/any-hostname/
Pre-clearance: https://developers.cloudflare.com/turnstile/additional-configuration/hostname-management/pre-clearance/
Cloudflare clearance: https://developers.cloudflare.com/cloudflare-challenges/concepts/clearance/
Ephemeral IDs: https://developers.cloudflare.com/turnstile/additional-configuration/ephemeral-id/

# Cloudflare Turnstile 攻防設計：システム原理とコントロールプレーン

一いち、システム原理システムげんり

1.1 Turnstile は「能力のうりょくトークン」システムである

1.2 Token の三みっつの安全あんぜんセマンティクス

1.3 チャレンジ実行じっこうチェーンは「クロスオリジン実行クロスオリジンじっこうシステム」である

1.4 リスクスコアリング：入力にゅうりょくは「真偽しんぎ」ではなく「自己整合性じこせいごうせい」である

1.5 反はんデバッグスクリプトは独立どくりつした攻撃面こうげきめんであり、フィンガープリント命中めいちゅうと同一どういつではない

1.6 スコープバインディング：hostname / action / cdata

1.7 Token 状態機械じょうたいきかい（能力のうりょくトークンの視点してん）

1.8 攻撃木こうげきぎ（上位じょういレベル）

二に、コントロールプレーン設計コントロールプレーンせっけい（攻防こうぼうの視点してん）

2.1 コントロールプレーンの階層化かいそうか

2.2 チャレンジ実行制御じっこうせいぎょ：クロスオリジンセマンティクス保護ほごを優先ゆうせんする

2.3 サーバー側がわ消費制御しょうひせいぎょ：token を能力のうりょくとして消費しょうひする

2.4 スコープ制御スコープせいぎょ：Hostname Management と Any Hostname

2.5 摩擦制御まさつせいぎょ：Pre-clearance と cf_clearance の境界きょうかい

2.6 高対抗こうたいこうシナリオ：プロキシプールとデバイス関連付デバイスかんれんづけ

三さん、方案設計ほうあんせっけいの優先順位ゆうせんじゅんい

公式参考こうしきさんこう（概念がいねんと設定せってい）

管理者コンテンツ操作

コメント