# ブラウザ自動化の攻防設計：検出モデルと階層型コントロールプレーン

本稿ほんこうは、ブラウザ自動化じどうかにおける攻防戦略こうぼうせんりゃくの設計せっけいに焦点しょうてんを当あて、二つの部分ぶぶんに分わけて扱あつかう。

1. 原則げんそく：リスクスコアリングシステムがどのように結論けつろんを導みちびくか
2. コントロールプレーン：階層設計かいそうせっけいがどのようにリスクと変動へんどうを低減ていげんするか

本稿ほんこうには、コマンドライン操作そうさや工程実装こうていじっそうの手順てじゅんは含ふくまない。

Turnstile 関連かんれん内容ないよう： Cloudflare Turnstile 攻防設計こうぼうせっけい：システム原則げんそくとコントロールプレーン

1. 原則げんそく

1.1 リスクスコアリングは単一たんいつポイントの命中めいちゅうではない

高たかリスク制御せいぎょのあるサイトでは、「チャレンジするか / 権限けんげんを下さげるか」という判断はんだんは、通常つうじょう、単一たんいつのルールによる二値判断にちはんだんではなく、多次元たじげんスコアリングから生うまれる。

主おもな入力次元にゅうりょくじげん：

1. 一貫性いっかんせい：同一どういつ身元みもとが異ことなる観測可能面かんそくかのうめんの間あいだで自己矛盾じこむじゅんしていないか
2. 希少性きしょうせい：低頻度ていひんどの異常いじょうな組くみ合あわせが出現しゅつげんしていないか
3. 時間特徴じかんとくちょう：行動こうどうの時系列じけいれつが機械的きかいてきな統計特徴とうけいとくちょうを示しめしていないか
4. 実行完全性じっこうかんぜんせい：重要じゅうような経路けいろ（チャレンジスクリプト、クロスオリジンリソース、worker）が破壊はかいされていないか

flowchart LR
  A["Environment & behavior"] --> B["Consistency score"]
  A --> C["Rarity score"]
  A --> D["Temporal score"]
  A --> E["Execution integrity score"]
  B --> F["Overall risk"]
  C --> F
  D --> F
  E --> F
  F --> G{"Allow / Challenge / Rate limit"}

1.2 一貫性いっかんせい：単一たんいつの微調整びちょうせいではなく、制約せいやくの集合しゅうごう

一貫性いっかんせいの問題もんだいの本質ほんしつは、「同一どういつ身元みもとについて、複数ふくすうの観測可能面かんそくかのうめんにまたがる制約せいやくが同時どうじに成立せいりつしなければならない」という点てんにある。

1.2.1 制約集合せいやくしゅうごうの模式図もしきず

身元みもとの一貫性いっかんせいは、「制約せいやくグラフ」としてモデル化かできる。

flowchart TD
  UA["UA string"] --> UACH["UA-CH / userAgentMetadata"]
  UA --> LangH["Accept-Language"]
  LangH --> LangJS["navigator.language(s)"]
  LangJS --> Intl["Intl locale/timeZone"]
  Plat["platform"] --> Rend["Rendering capability / WebGL"]
  Rend --> Win["Window/screen parameters"]
  UACH --> Plat

図ずのそれぞれの辺へんは、「この二つの観測可能面かんそくかのうめんは相互そうごに一貫いっかんしていなければならない」ことを表あらわす。そうでなければ、衝突しょうとつスコアが発生はっせいする。

1.2.2 典型的てんけいてきな衝突しょうとつタイプ

• UA が示しめすプラットフォーム/バージョンと UA-CH が一致いっちしない
• Accept-Language と navigator.languages が一致いっちしない
• Intl のタイムゾーンと推定すいていされたオフセット/地域ちいきが一致いっちしない
• デバイス宣言せんげんとレンダリング能力のうりょくの組くみ合あわせが異常いじょう

工学的こうがくてき意味いみ：

• 一つの点てんを修正しゅうせいすると、別べつの点てんを壊こわす可能性かのうせいがある
• 設計順序せっけいじゅんじょは、「まず制約集合せいやくしゅうごうを定義ていぎし、次にそれぞれの観測可能面かんそくかのうめんがそれらの制約せいやくをどう満みたすかを決きめる」であるべきだ

1.3 希少性きしょうせい：単一値たんいつちリスクではなく、組くみ合あわせリスク

希少性きしょうせいは「低頻度ていひんどの組くみ合あわせ」から生うまれる。危険きけんは、どれか単一たんいつの項目こうもくではなく、共起きょうきから生うまれる。

希少性きしょうせいは、「同時分布どうじぶんぷ」からの逸脱いつだつとして理解りかいできる。

• 単一因子たんいついんしの逸脱いつだつ：許容きょようされる可能性かのうせいがある
• 複数ふくすうの逸脱いつだつが同時どうじに出現しゅつげん：リスクが急速きゅうそくに蓄積ちくせきする

工学的こうがくてき意味いみ：

• 目標もくひょうは、同一どういつセッションにおける低頻度ていひんどの組くみ合あわせの重かさなりを減へらすこと
• 目標もくひょうは、ある固定こていプロファイルに適合てきごうさせることではない

1.4 時間特徴じかんとくちょう：行動意味こうどういみではなく、統計特徴とうけいとくちょう

行動検出こうどうけんしゅつでは、通常つうじょう、統計分布とうけいぶんぷの特徴とくちょうに注目ちゅうもくする。

• 低分散ていぶんさん：動作間隔どうさかんかくが安定あんていしすぎている
• 強つよい周期性しゅうきせい：間隔かんかくが固定こていリズムに従したがう
• 強つよい同期性どうきせい：異ことなる動作どうさタイプの間隔かんかくが互たがいに揃そろう

工学的こうがくてき意味いみ：

• 行動治理こうどうちりの目標もくひょうは「分布整形ぶんぷせいけい」（分散ぶんさん/ゆらぎ/jitter/退避たいひ/backoff）である
• 行動治理こうどうちりは「より多おおくの動作どうさを増ふやすこと」ではない

1.5 実行完全性じっこうかんぜんせい：上流じょうりゅうの前提条件ぜんていじょうけん

実行完全性じっこうかんぜんせいは、「システムが正ただしく実行じっこうできるか」の前提条件ぜんていじょうけんである。

• チャレンジスクリプト、クロスオリジン iframe、またはクロスオリジン worker の意味的経路いみてきけいろが破壊はかいされると、失敗率しっぱいりつは大幅おおはばに上昇じょうしょうする
• この種しゅの失敗しっぱいは、「識別しきべつされたかどうか」とは異ことなる分類ぶんるいである可能性かのうせいがある

工学原則こうがくげんそく：

信号しんごうの微調整びちょうせいよりも、実行じっこうチェーンの保護ほごを優先ゆうせんする。

1.6 反はんデバッグ実行面じっこうめん：フィンガープリントスコアリング面めんと並行へいこう

多おおくのサイトは、フィンガープリントスコアリングだけに依存いぞんせず、「能動的修復型のうどうてきしゅうふくがた反はんデバッグ」スクリプトも配置はいちする。

典型的てんけいてきな経路けいろ：

flowchart LR
  A["Page start"] --> B["Anti-debug detection"]
  B --> C{"Hit?"}
  C -->|Yes| D["close / back / redirect"]
  C -->|No| E["Continue business logic"]

フィンガープリントスコアリング面めんとの関係かんけい：

1. フィンガープリントスコアリングは「チャレンジ / 通過つうか / 降格こうかく」を決定けっていする
2. 反はんデバッグ修復しゅうふくは「ページが引ひき続つづき利用可能りようかのうか」を決定けっていする

したがって、「ページが自分じぶんで閉とじる」ことから、ただちに「フィンガープリントが識別しきべつされた」と推論すいろんすることはできない。より一般的いっぱんてきには、反はんデバッグチェーンが発火はっかした結果けっかである。

2. コントロールプレーン（階層設計かいそうせっけい）

2.1 コントロールプレーン概観がいかん

一つの攻防戦略こうぼうせんりゃくは、四つの層そうのコントロールプレーンに分解ぶんかいできる。

1. 起動制御きどうせいぎょ：起動初期きどうしょきに明示的めいじてきリスクを治理ちりする
2. プロトコル制御せいぎょ：プロトコル層そうの身元一貫性みもといっかんせいを治理ちりする
3. ランタイム制御せいぎょ：ページスクリプトの観測可能面かんそくかのうめんを治理ちりする
4. 行動こうどうとセッション制御せいぎょ：時間分布じかんぶんぷとコンテキストドリフトを治理ちりする

flowchart LR
  A["Startup control"] --> B["Protocol control"]
  B --> C["Runtime control"]
  C --> D["Behavior & session control"]
  D --> E["Consistency & stability"]

2.2 起動制御きどうせいぎょ

目標もくひょう：セッション初期しょきに明示的めいじてきリスクを低減ていげんする。

設計制約せっけいせいやく：

• 高信頼度こうしんらいどの自動化識別子じどうかしきべつしのみを処理しょりする
• プロトコル層そうまたはランタイム層そうと不一致ふいっちになる変更へんこうの導入どうにゅうを避さける

2.3 プロトコル制御せいぎょ

目標もくひょう：プロトコル層そうの出力しゅつりょくで身元みもとの制約集合せいやくしゅうごうを実現じつげんする。

設計せっけいの要点ようてん：

• UA と UA-CH を、同一どういつ制約集合せいやくしゅうごうの異ことなる投影とうえいとみなす
• 適用範囲てきようはんいは対象たいしょうスコープと揃そろえる必要ひつようがある（pages/workers/subtargets）

2.4 ランタイム制御せいぎょ

目標もくひょう：高頻度こうひんどの探索面たんさくめんをカバーしつつ、実行意味じっこういみを破壊はかいしないようにする。

設計せっけいの要点ようてん：

• 高頻度こうひんどで説明可能せつめいかのうな探索経路たんさくけいろを優先的ゆうせんてきに治理ちりする
• クロスオリジンのチャレンジチェーン対象たいしょうには、厳格げんかくな注入境界ちゅうにゅうきょうかいを設定せっていする

2.4.1 反はんデバッグスクリプトの治理ちり（disable-devtool ライブラリを例れいとして）

反はんデバッグスクリプトは、しばしば固定こていされた起動入口きどういりぐちから発火はっかする（例たとえば disable-devtool-auto マーカー）。

実行可能じっこうかのうな制御戦略せいぎょせんりゃく：

1. 自動起動入口じどうきどういりぐちのみを抑制よくせいし、能動的修復のうどうてきしゅうふくの発火はっかを避さける
2. 汎用的はんようてきなクエリ/スクリプトロードの意味いみを書かき換かえず、業務ぎょうむページへの影響えいきょうを避さける
3. 治理範囲ちりはんいを高信頼度こうしんらいどの発火点はっかてんに限定げんていし、副作用面ふくさようめんを制御せいぎょする

これらの戦略せんりゃくの本質ほんしつは「実行面じっこうめんの隔離かくり」であり、「より多おおくのフィンガープリントを偽造ぎぞうすること」ではない。

2.5 行動こうどうとセッション制御せいぎょ

目標もくひょう：時間分布じかんぶんぷを整形せいけいし、コンテキストドリフトを低減ていげんする。

設計せっけいの要点ようてん：

• 行動治理こうどうちりは統計分布とうけいぶんぷ（分散ぶんさん/ゆらぎ/jitter/退避たいひ/backoff）に向むける
• セッション治理ちりは一貫いっかんしたコンテキスト（身元みもとドリフトの回避かいひ）に向むける

2.6 チャレンジ場面ばめん（Turnstile）のコントロールプレーン要約ようやく

Turnstile の場面ばめんでは、重要じゅうようなコントロールプレーンは次つぎのように抽象化ちゅうしょうかできる。

1. 能力のうりょくトークンの意味いみ：サーバー側がわ検証けんしょう、有限ゆうげんの有効期間ゆうこうきかん、一回限いっかいかぎりの消費しょうひ
2. 範囲収束はんいしゅうそく：hostname/action/cdata によって悪用空間あくようくうかんを狭せばめる
3. 実行じっこうチェーン保護ほご：クロスオリジンのスクリプト/iframe/worker の意味いみを保護ほごする
4. 摩擦まさつとセキュリティの分離ぶんり：clearance は体験層たいけんそうに属ぞくし、セキュリティ判断層はんだんそうを代替だいたいしない

この要約ようやくは、Turnstile を統一とういつコントロールプレーン枠組わくぐみに組くみ込こむためのものだ。詳細しょうさいは別稿べっこうを参照さんしょう。

3. 設計優先度せっけいゆうせんど

コントロールプレーンの設計せっけいは、通常つうじょう、次つぎの優先度ゆうせんどで進すすめる。

1. 実行完全性じっこうかんぜんせい（チェーンが実行可能じっこうかのうであることを確保かくほする。反はんデバッグ発火面はっかめんへの治理ちりを含ふくむ）
2. 一貫性制約集合いっかんせいせいやくしゅうごう（観測可能面かんそくかのうめんをまたぐ矛盾むじゅんを解消かいしょうする）
3. 希少性制御きしょうせいせいぎょ（低頻度ていひんどの組くみ合あわせの重かさなりを避さける）
4. 時間分布整形じかんぶんぷせいけい（機械的きかいてきな統計特徴とうけいとくちょうを低減ていげんする）
5. 体験最適化たいけんさいてきか（反復はんぷくチャレンジがもたらす摩擦まさつを減へらす）

この順序じゅんじょの意味いみは、まず「システムの正ただしさ」を確保かくほし、その後あとに「安定性あんていせいと摩擦まさつ」を最適化さいてきかする、ということだ。