Translated ['src/pentesting-ci-cd/cloudflare-security/README.md', 'src/p

src/pentesting-ci-cd/cloudflare-security/README.md

@@ -1,12 +1,12 @@
-# Cloudflare セキュリティ
+# Cloudflare Security
 
 {{#include ../../banners/hacktricks-training.md}}
 
-In a Cloudflare account there are some **一般的な設定とサービス** that can be configured. In this page we are going to **各セクションのセキュリティ関連設定を分析します:**
+In a Cloudflare account there are some **general settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:**
 
 <figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>
 
-## Webサイト
+## Websites
 
 Review each with:
 
@@ -14,10 +14,9 @@ Review each with:
 cloudflare-domains.md
 {{#endref}}
 
-### ドメイン登録
+### Domain Registration
 
 - [ ] In **`Transfer Domains`** check that it's not possible to transfer any domain.
-  - **`Transfer Domains`** で任意のドメインを転送できないことを確認する。
 
 Review each with:
 
@@ -33,37 +32,27 @@ _I couldn't find anything to check for a config security review._
 
 On each Cloudflare's page:
 
-- [ ] Check for **機密情報** in the **`Build log`**.
-- [ ] Check for **機密情報** in the **Github repository** assigned to the pages.
+- [ ] Check for **sensitive information** in the **`Build log`**.
+- [ ] Check for **sensitive information** in the **Github repository** assigned to the pages.
 - [ ] Check for potential github repo compromise via **workflow command injection** or `pull_request_target` compromise. More info in the [**Github Security page**](../github-security/index.html).
 - [ ] Check for **vulnerable functions** in the `/fuctions` directory (if any), check the **redirects** in the `_redirects` file (if any) and **misconfigured headers** in the `_headers` file (if any).
-  - `/fuctions` ディレクトリ（存在する場合）の脆弱な関数を確認し、`_redirects` ファイル（存在する場合）のリダイレクトと `_headers` ファイル（存在する場合）の誤設定されたヘッダを確認する。
 - [ ] Check for **vulnerabilities** in the **web page** via **blackbox** or **whitebox** if you can **access the code**
-  - コードにアクセスできる場合は、**blackbox** または **whitebox** によってウェブページの脆弱性を確認する。
 - [ ] In the details of each page `/<page_id>/pages/view/blocklist/settings/functions`. Check for **sensitive information** in the **`Environment variables`**.
-  - 各ページの詳細 `/<page_id>/pages/view/blocklist/settings/functions` で、**`Environment variables`** に機密情報が含まれていないか確認する。
 - [ ] In the details page check also the **build command** and **root directory** for **potential injections** to compromise the page.
-  - 詳細ページで **build command** と **root directory** を確認し、ページを乗っ取る可能性のある注入がないか確認する。
 
 ## **Workers**
 
 On each Cloudflare's worker check:
 
 - [ ] The triggers: What makes the worker trigger? Can a **user send data** that will be **used** by the worker?
-  - トリガー: Worker を起動する要因は何か？**ユーザがデータを送信**して、それが **使用される** か？
 - [ ] In the **`Settings`**, check for **`Variables`** containing **sensitive information**
-  - **`Settings`** で **`Variables`** に機密情報が含まれていないか確認する
 - [ ] Check the **code of the worker** and search for **vulnerabilities** (specially in places where the user can manage the input)
-  - Worker のコードを確認し、特にユーザが入力を扱う箇所で脆弱性がないか確認する
 - Check for SSRFs returning the indicated page that you can control
-  - あなたが制御できるページを返す SSRF を確認する
 - Check XSSs executing JS inside a svg image
-  - svg 画像内で JS を実行する XSS を確認する
 - It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input.
-  - Worker が他の内部サービスと連携している可能性がある。例えば、Worker が入力から得た情報を保存する R2 バケットとやり取りする場合、その Worker が R2 バケットに対してどのような権限を持っているか、ユーザ入力からどのように悪用され得るかを確認する必要がある。
 
 > [!WARNING]
-> デフォルトでは **Worker に割り当てられる URL** は `<worker-name>.<account>.workers.dev` のようになります。ユーザはそれを **サブドメイン** に設定できますが、知っていれば常にその **元の URL** でアクセスできます。
+> Note that by default a **Worker is given a URL** such as `<worker-name>.<account>.workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it.
 
 For a practical abuse of Workers as pass-through proxies (IP rotation, FireProx-style), check:
 
@@ -76,7 +65,6 @@ cloudflare-workers-pass-through-proxy-ip-rotation.md
 On each R2 bucket check:
 
 - [ ] Configure **CORS Policy**.
-  - **CORS Policy** を設定する。
 
 ## Stream
 
@@ -89,9 +77,7 @@ TODO
 ## Security Center
 
 - [ ] If possible, run a **`Security Insights`** **scan** and an **`Infrastructure`** **scan**, as they will **highlight** interesting information **security** wise.
-  - 可能なら **`Security Insights`** スキャンと **`Infrastructure`** スキャンを実行する。これらはセキュリティ上興味深い情報を強調表示する。
 - [ ] Just **check this information** for security misconfigurations and interesting info
-  - この情報をセキュリティの誤設定や興味深い情報のために確認する
 
 ## Turnstile
 
@@ -106,12 +92,10 @@ cloudflare-zero-trust-network.md
 ## Bulk Redirects
 
 > [!NOTE]
-> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) は本質的に静的で、文字列置換操作や正規表現を**サポートしません**。ただし、URL のマッチング動作や実行時の動作に影響する URL redirect parameters を設定することはできます。
+> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) are essentially static — they do **not support any string replacement** operations or regular expressions. However, you can configure URL redirect parameters that affect their URL matching behavior and their runtime behavior.
 
 - [ ] Check that the **expressions** and **requirements** for redirects **make sense**.
-  - リダイレクトの **expressions** と **requirements** が妥当であるか確認する。
 - [ ] Check also for **sensitive hidden endpoints** that you contain interesting info.
-  - 興味深い情報を含む **機密の隠しエンドポイント** がないかも確認する。
 
 ## Notifications
 
@@ -136,27 +120,18 @@ cloudflare-zero-trust-network.md
 - `Advanced Security Events Alert`
 - `Security Events Alert`
 - [ ] Check all the **destinations**, as there could be **sensitive info** (basic http auth) in webhook urls. Make also sure webhook urls use **HTTPS**
-  - すべての **destinations** を確認する。webhook URL に基本認証などの **機密情報** が含まれている可能性があるため。また webhook URL が **HTTPS** を使用していることを確認する。
 - [ ] As extra check, you could try to **impersonate a cloudflare notification** to a third party, maybe you can somehow **inject something dangerous**
-  - 追加の確認として、Cloudflare 通知を第三者に**偽装**してみることが考えられる。何らかの方法で**危険な注入**ができないか検証する。
 
 ## Manage Account
 
 - [ ] It's possible to see the **last 4 digits of the credit card**, **expiration** time and **billing address** in **`Billing` -> `Payment info`**.
-  - **`Billing` -> `Payment info`** でクレジットカードの**下4桁**、**有効期限**、**請求先住所**を確認できる。
 - [ ] It's possible to see the **plan type** used in the account in **`Billing` -> `Subscriptions`**.
-  - **`Billing` -> `Subscriptions`** でアカウントの**プラン種別**を確認できる。
 - [ ] In **`Members`** it's possible to see all the members of the account and their **role**. Note that if the plan type isn't Enterprise, only 2 roles exist: Administrator and Super Administrator. But if the used **plan is Enterprise**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) can be used to follow the least privilege principle.
-  - **`Members`** ではアカウントの全メンバーとそのロールを確認できる。プランが Enterprise でない場合、ロールは Administrator と Super Administrator の2種類のみである。使用中のプランが Enterprise の場合は、最小権限の原則に従うために [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) を利用できる。
 - Therefore, whenever possible is **recommended** to use the **Enterprise plan**.
-  - したがって、可能な限り **Enterprise プラン** を利用することを**推奨**する。
 - [ ] In Members it's possible to check which **members** has **2FA enabled**. **Every** user should have it enabled.
-  - **`Members`** でどのメンバーが **2FA を有効化しているか** を確認できる。すべてのユーザが有効化しているべきである。
 
 > [!NOTE]
 > Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members)
-> 
-> 幸いなことに、ロール **`Administrator`** はメンバーシップを管理する権限を与えない（**権限昇格や新規メンバー招待はできない**）。
 
 ## DDoS Investigation
 

src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md

@@ -1,31 +1,31 @@
-# Cloudflare Workers をパススルー プロキシとして悪用する（IPローテーション、FireProx-style）
+# Cloudflare Workersをpass-through proxiesとして悪用する (IP rotation, FireProx-style)
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Cloudflare Workers は、アップストリームのターゲット URL をクライアントが指定する透明な HTTP パススルー プロキシとしてデプロイできます。リクエストは Cloudflare のネットワークから発信されるため、ターゲット側にはクライアントの IP の代わりに Cloudflare の IP が表示されます。これは AWS API Gateway 上のよく知られた FireProx 技術と同様ですが、Cloudflare Workers を使用します。
+Cloudflare Workersは、上流のターゲットURLがクライアントによって指定される透明なHTTP pass-through proxiesとしてデプロイできます。リクエストはCloudflareのネットワークから送出されるため、ターゲット側にはクライアントではなくCloudflareのIPsが見えます。これはAWS API Gateway上のよく知られたFireProx手法を踏襲しますが、Cloudflare Workersを使用します。
 
-### Key capabilities
-- 全ての HTTP メソッドをサポート (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
-- ターゲットはクエリパラメータ (?url=...)、ヘッダ (X-Target-URL)、あるいはパスにエンコード (/https://target など) して渡せる
-- 必要に応じて hop-by-hop/ヘッダフィルタリングを行い、ヘッダとボディをそのままプロキシ
-- ステータスコードと大半のヘッダを保持してレスポンスを中継
-- 任意で X-Forwarded-For を偽装可能（Worker がユーザ制御のヘッダから設定する場合）
-- 複数の Worker エンドポイントをデプロイしてリクエストを分散させることで、非常に高速/簡単にローテーション可能
+### 主な機能
+- すべてのHTTPメソッド（GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD）をサポート
+- ターゲットはクエリパラメータ（?url=...）、ヘッダ（X-Target-URL）、あるいはパス内にエンコード（例：/https://target）して渡せる
+- 必要に応じてhop-by-hop/ヘッダフィルタリングを行いながらヘッダとボディをプロキシ
+- ステータスコードと大半のヘッダを保持してレスポンスを返送
+- （Workerがユーザー制御ヘッダから設定する場合など）X-Forwarded-Forの偽装が可能
+- 複数のWorkerエンドポイントをデプロイしてリクエストを扇形に広げることで、非常に高速かつ容易にローテーション可能
 
-### 仕組み（フロー）
-1) クライアントは Worker の URL（`<name>.<account>.workers.dev` またはカスタムドメインのルート）に HTTP リクエストを送る。  
-2) Worker はターゲットをクエリパラメータ (?url=...)、X-Target-URL ヘッダ、または実装されていればパスセグメントから抽出する。  
-3) Worker は受け取ったメソッド、ヘッダ、ボディを指定されたアップストリーム URL に転送する（問題のあるヘッダはフィルタリングする）。  
-4) アップストリームのレスポンスは Cloudflare 経由でクライアントにストリーミングされる；オリジン側には Cloudflare の送信元 IP が見える。
+### 動作の仕組み（フロー）
+1) クライアントがWorkerのURL（`<name>.<account>.workers.dev` またはカスタムドメインルート）にHTTPリクエストを送信する。  
+2) Workerはターゲットをクエリパラメータ（?url=...）、X-Target-URLヘッダ、あるいは実装されていればパスセグメントから抽出する。  
+3) Workerは受信したメソッド、ヘッダ、ボディを指定された上流URLへ転送する（問題のあるヘッダはフィルタリング）。  
+4) 上流のレスポンスはCloudflare経由でクライアントにストリーミングされる。オリジン側にはCloudflareのIPsが見える。
 
 ### Worker 実装例
-- ターゲット URL をクエリパラメータ、ヘッダ、またはパスから読み取る  
-- 安全なサブセットのヘッダをコピーして元のメソッド/ボディを転送する  
-- 任意でユーザ制御のヘッダ (X-My-X-Forwarded-For) かランダム IP を使って X-Forwarded-For を設定する  
-- 許容的な CORS を追加し、プリフライトを処理する
+- クエリパラメータ、ヘッダ、またはパスからターゲットURLを読み取る
+- 安全なヘッダのサブセットをコピーし、元のメソッド/ボディを転送
+- 任意でユーザー制御ヘッダ（X-My-X-Forwarded-For）やランダムIPを使用してX-Forwarded-Forを設定
+- 寛容なCORSを追加し、preflightを処理
 
 <details>
-<summary>パススルー プロキシ用の Worker (JavaScript) 例</summary>
+<summary>pass-through proxying用のサンプル Worker (JavaScript)</summary>
 ```javascript
 /**
 * Minimal Worker pass-through proxy
@@ -133,19 +133,19 @@ function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1
 ```
 </details>
 
-### FlareProxを使ったデプロイとローテーションの自動化
+### FlareProx を使ったデプロイとローテーションの自動化
 
-FlareProxはPython製のツールで、Cloudflare APIを利用して多数の Worker endpoints をデプロイし、それらを順次ローテーションします。これによりCloudflareのネットワークからFireProx-likeなIPローテーションを提供します。
+FlareProx は Cloudflare API を使用して多数の Worker エンドポイントをデプロイし、それらを順にローテートする Python ツールです。これにより Cloudflare’s network からの FireProx のような IP ローテーションが可能になります。
 
 セットアップ
-1) “Edit Cloudflare Workers”テンプレートを使用してCloudflare API Tokenを作成し、ダッシュボードからAccount IDを取得します。
-2) FlareProxを設定する:
+1) “Edit Cloudflare Workers” テンプレートを使って Cloudflare API Token を作成し、ダッシュボードから Account ID を取得します。
+2) FlareProx を設定する:
 ```bash
 git clone https://github.com/MrTurvey/flareprox
 cd flareprox
 pip install -r requirements.txt
 ```
-**flareprox.json の設定ファイルを作成:**
+**flareprox.json の config file を作成する:**
 ```json
 {
 "cloudflare": {
@@ -156,28 +156,28 @@ pip install -r requirements.txt
 ```
 **CLI の使用方法**
 
-- N 個の Worker proxies を作成する:
+- N 個の Worker proxies を作成:
 ```bash
 python3 flareprox.py create --count 2
 ```
-- エンドポイントを一覧表示:
+- endpoints を一覧表示:
 ```bash
 python3 flareprox.py list
 ```
-- ヘルスチェック用のエンドポイント:
+- ヘルスチェックエンドポイント:
 ```bash
 python3 flareprox.py test
 ```
-- すべてのエンドポイントを削除する:
+- すべての endpoints を削除する:
 ```bash
 python3 flareprox.py cleanup
 ```
-**Workerを経由したトラフィックのルーティング**
+**Routing traffic through a Worker**
 - クエリパラメータ形式:
 ```bash
 curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip"
 ```
-- ヘッダー形式:
+ヘッダー形式:
 ```bash
 curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.workers.dev
 ```
@@ -185,7 +185,7 @@ curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.worke
 ```bash
 curl https://your-worker.account.workers.dev/https://httpbin.org/ip
 ```
-- メソッドの例:
+- 手法の例:
 ```bash
 # GET
 curl "https://your-worker.account.workers.dev?url=https://httpbin.org/get"
@@ -204,17 +204,17 @@ curl -X DELETE \
 ```
 **`X-Forwarded-For` 制御**
 
-Workerが`X-My-X-Forwarded-For`を尊重する場合、上流の`X-Forwarded-For`ヘッダの値に影響を与えられます：
+Worker が `X-My-X-Forwarded-For` を尊重する場合、上流の `X-Forwarded-For` 値に影響を与えられます:
 ```bash
 curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
 "https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
 ```
-**プログラムからの利用**
+**プログラムでの使用方法**
 
-Use the FlareProx library to create/list/test endpoints and route requests from Python.
+FlareProxライブラリを使用して、エンドポイントの作成、一覧表示、テストを行い、Pythonからリクエストをルーティングします。
 
 <details>
-<summary>Python の例: ランダムな Worker エンドポイント経由で POST を送信する</summary>
+<summary>Pythonの例: ランダムな Worker エンドポイント経由で POST を送信</summary>
 ```python
 #!/usr/bin/env python3
 from flareprox import FlareProx, FlareProxError
@@ -267,17 +267,17 @@ print(f"Request error: {e}")
 ```
 </details>
 
-**Burp/Scanner の連携**
+**Burp/Scanner 統合**
 - ツール（例: Burp Suite）を Worker URL に向ける。
-- 実際のアップストリームは ?url= または X-Target-URL を使って指定する。
-- HTTP semantics (methods/headers/body) は保持され、source IP は Cloudflare の背後にマスクされる。
+- ?url= または X-Target-URL を使って実際の upstream を指定する。
+- HTTP のセマンティクス（methods/headers/body）は保持され、送信元 IP は Cloudflare の背後に隠される。
 
-**運用上の注意点と制限**
-- Cloudflare Workers の Free プランでは、1アカウントあたり概ね 100,000 リクエスト/日 が可能。必要に応じてトラフィックを分散するために複数のエンドポイントを使用する。
-- Workers は Cloudflare のネットワーク上で実行される。多くのターゲットは Cloudflare の IPs/ASN のみを検出し、単純な IP の許可/拒否リストや地理的ヒューリスティクスを回避できる可能性がある。
-- 権限のある場合にのみ責任を持って使用すること。ToS と robots.txt を順守すること。
+**運用上の注意と制限**
+- Cloudflare Workers Free プランではアカウントあたり概ね 100,000 リクエスト/日が許容される。必要なら複数のエンドポイントでトラフィックを分散すること。
+- Workers は Cloudflare のネットワーク上で実行されるため、多くのターゲットは Cloudflare の IP/ASN のみを認識する。これにより単純な IP の許可/拒否リストやジオヒューリスティックを回避できる可能性がある。
+- 責任を持って、かつ必ず許可を得た上で使用すること。ToS と robots.txt を順守すること。
 
-## 参考資料
+## References
 - [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox)
 - [Cloudflare Workers fetch() API](https://developers.cloudflare.com/workers/runtime-apis/fetch/)
 - [Cloudflare Workers pricing and free tier](https://developers.cloudflare.com/workers/platform/pricing/)