diff --git a/src/pentesting-web/csrf-cross-site-request-forgery.md b/src/pentesting-web/csrf-cross-site-request-forgery.md
index 067bf91ff..3af6ade6a 100644
--- a/src/pentesting-web/csrf-cross-site-request-forgery.md
+++ b/src/pentesting-web/csrf-cross-site-request-forgery.md
@@ -1,86 +1,114 @@
-# CSRF (クロスサイトリクエストフォージェリ)
+# CSRF (Cross Site Request Forgery)
{{#include ../banners/hacktricks-training.md}}
-## クロスサイトリクエストフォージェリ (CSRF) の説明
+## Cross-Site Request Forgery (CSRF) Explained
-**クロスサイトリクエストフォージェリ (CSRF)** は、ウェブアプリケーションに見られるセキュリティ脆弱性の一種です。これにより、攻撃者は認証されたセッションを悪用して、無防備なユーザーの代わりにアクションを実行できます。攻撃は、被害者のプラットフォームにログインしているユーザーが悪意のあるサイトを訪れたときに実行されます。このサイトは、JavaScriptの実行、フォームの送信、または画像の取得などの方法を通じて、被害者のアカウントへのリクエストをトリガーします。
+**Cross-Site Request Forgery (CSRF)** は、ウェブアプリケーションに見られるセキュリティ脆弱性の一種です。攻撃者は認証済みセッションを悪用して、ユーザーに気付かれないうちにそのユーザーの代わりに操作を行わせることができます。攻撃は、被害者のプラットフォームにログイン中のユーザーが悪意のあるサイトを訪れたときに実行され、そのサイトが JavaScript の実行、フォームの送信、画像の取得などで被害者アカウントへリクエストを送信します。
-### CSRF攻撃の前提条件
+### Prerequisites for a CSRF Attack
-CSRF脆弱性を悪用するには、いくつかの条件を満たす必要があります：
+CSRF 脆弱性を悪用するには、いくつかの条件が満たされている必要があります:
-1. **価値のあるアクションを特定する**: 攻撃者は、ユーザーのパスワード、メールアドレスの変更、または権限の昇格など、悪用する価値のあるアクションを見つける必要があります。
-2. **セッション管理**: ユーザーのセッションは、クッキーまたはHTTP基本認証ヘッダーを通じてのみ管理されるべきです。他のヘッダーはこの目的のために操作できません。
-3. **予測不可能なパラメータの不在**: リクエストには予測不可能なパラメータが含まれていない必要があります。これらは攻撃を妨げる可能性があります。
+1. **Identify a Valuable Action**: 攻撃者は、パスワードやメールの変更、権限昇格など、悪用価値のあるアクションを見つける必要があります。
+2. **Session Management**: ユーザーのセッションが cookies や HTTP Basic Authentication header のみで管理されている必要があります。他のヘッダはこの目的で操作できないためです。
+3. **Absence of Unpredictable Parameters**: リクエストに予測不可能なパラメータが含まれていると、攻撃が阻止される可能性があります。
-### クイックチェック
+### Quick Check
-**Burpでリクエストをキャプチャ**し、CSRF保護を確認することができます。また、ブラウザからテストするには、**Copy as fetch**をクリックしてリクエストを確認できます：
+Burp でリクエストをキャプチャして CSRF 保護を確認できます。ブラウザからテストするには、**Copy as fetch** をクリックしてリクエストを確認してください:
 (1) (1).png)
-### CSRFに対する防御
+### Defending Against CSRF
-CSRF攻撃から保護するために実装できるいくつかの対策があります：
+CSRF 攻撃から守るために実装できる対策はいくつかあります:
-- [**SameSiteクッキー**](hacking-with-cookies/index.html#samesite): この属性は、ブラウザがクロスサイトリクエストと共にクッキーを送信するのを防ぎます。[SameSiteクッキーの詳細](hacking-with-cookies/index.html#samesite)。
-- [**クロスオリジンリソースシェアリング**](cors-bypass.md): 被害者サイトのCORSポリシーは、攻撃の実行可能性に影響を与える可能性があります。特に、攻撃が被害者サイトからの応答を読み取る必要がある場合。[CORSバイパスについて学ぶ](cors-bypass.md)。
-- **ユーザー確認**: ユーザーのパスワードを求めたり、キャプチャを解決させたりすることで、ユーザーの意図を確認できます。
-- **リファラーまたはオリジンヘッダーの確認**: これらのヘッダーを検証することで、リクエストが信頼できるソースから来ていることを確認できます。ただし、URLを慎重に作成することで、実装が不十分なチェックを回避できる場合があります。例えば：
- - `http://mal.net?orig=http://example.com`（URLが信頼できるURLで終わる）
- - `http://example.com.mal.net`（URLが信頼できるURLで始まる）
-- **パラメータ名の変更**: POSTまたはGETリクエストのパラメータ名を変更することで、自動化された攻撃を防ぐのに役立ちます。
-- **CSRFトークン**: 各セッションにユニークなCSRFトークンを組み込み、以降のリクエストでこのトークンを要求することで、CSRFのリスクを大幅に軽減できます。トークンの効果はCORSを強制することで高めることができます。
+- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): この属性はブラウザがクロスサイトリクエストに対して cookies を送信するのを防ぎます。[More about SameSite cookies](hacking-with-cookies/index.html#samesite).
+- [**Cross-origin resource sharing**](cors-bypass.md): 被害者サイトの CORS ポリシーは、特に攻撃が被害者サイトのレスポンスを読む必要がある場合に攻撃の実現可能性に影響します。[Learn about CORS bypass](cors-bypass.md).
+- **User Verification**: ユーザーのパスワード再入力や captcha の提示により、ユーザーの意図を確認できます。
+- **Checking Referrer or Origin Headers**: これらのヘッダを検証することで、信頼できるソースからのリクエストかを判断できます。ただし、URL の巧妙な作り込みで不適切に実装されたチェックを回避できる場合があります。例:
+- `http://mal.net?orig=http://example.com`（URL が信頼された URL で終わる）
+- `http://example.com.mal.net`（URL が信頼された URL で始まる）
+- **Modifying Parameter Names**: POST や GET のパラメータ名を変更することで、自動化された攻撃を防ぐのに役立ちます。
+- **CSRF Tokens**: 各セッションに一意の CSRF トークンを組み込み、そのトークンを後続のリクエストで必須にすることで CSRF のリスクを大幅に軽減できます。CORS を併用するとトークンの有効性はさらに高まります。
-これらの防御を理解し実装することは、ウェブアプリケーションのセキュリティと整合性を維持するために重要です。
+これらの防御策を理解し実装することは、ウェブアプリケーションのセキュリティと完全性を維持する上で重要です。
-## 防御のバイパス
+## Defences Bypass
-### POSTからGETへ
+### From POST to GET (method-conditioned CSRF validation bypass)
-悪用したいフォームが**CSRFトークンを持つPOSTリクエストを送信するように準備されている**かもしれませんが、**GET**も**有効**であり、GETリクエストを送信したときに**CSRFトークンがまだ検証されているか**を**確認**する必要があります。
+一部のアプリケーションは POST に対してのみ CSRF 検証を強制し、他の HTTP メソッドではスキップすることがあります。PHP でよくあるアンチパターンは次のようになります:
+```php
+public function csrf_check($fatal = true) {
+if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF
+// ... validate __csrf_token here ...
+}
+```
+脆弱なエンドポイントが $_REQUEST からのパラメータも受け付ける場合、同じアクションを GET リクエストとして再発行し、CSRF token を完全に省略できます。これにより、POST 専用のアクションを token なしで成功する GET アクションに変換できます。
-### トークンの欠如
+Example:
-アプリケーションは、トークンが存在する場合に**トークンを検証するメカニズム**を実装しているかもしれません。しかし、トークンが存在しない場合に検証が完全にスキップされると、脆弱性が生じます。攻撃者は、トークンを持つパラメータを**削除すること**によってこれを悪用できます。これにより、検証プロセスを回避し、クロスサイトリクエストフォージェリ (CSRF) 攻撃を効果的に実行できます。
+- Original POST with token (intended):
-### CSRFトークンがユーザーセッションに結びついていない
+```http
+POST /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList HTTP/1.1
+Content-Type: application/x-www-form-urlencoded
-アプリケーションが**CSRFトークンをユーザーセッションに結びつけていない**場合、重大な**セキュリティリスク**が存在します。これらのシステムは、各トークンが開始セッションに結びついていることを確認するのではなく、**グローバルプール**に対してトークンを検証します。
+__csrf_token=sid:...&widgetInfoList=[{"widgetId":"https://attacker![]()
","widgetType":"URL"}]
+```
-攻撃者がこれを悪用する方法は次のとおりです：
+- Bypass by switching to GET (no token):
-1. **自分のアカウントを使用して認証**します。
-2. **グローバルプールから有効なCSRFトークンを取得**します。
-3. **このトークンを使用して**、被害者に対するCSRF攻撃を行います。
+```http
+GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoList=[{"widgetId":"https://attacker","widgetType":"URL"}] HTTP/1.1
+```
-この脆弱性により、攻撃者は被害者の代わりに無許可のリクエストを行うことができ、アプリケーションの**不十分なトークン検証メカニズム**を悪用します。
+Notes:
+- このパターンは、レスポンスが application/json ではなく誤って text/html として返される reflected XSS と一緒に現れることが多いです。
+- これを XSS と組み合わせると、脆弱なコードパスをトリガーしつつ CSRF チェックを完全に回避する単一の GET リンクを配布できるため、悪用のハードルが大幅に下がります。
-### メソッドバイパス
+### Lack of token
-リクエストが「**奇妙な**」**メソッド**を使用している場合、**メソッド**の**オーバーライド機能**が機能しているかを確認してください。たとえば、**PUT**メソッドを使用している場合、**POST**メソッドを使用して**送信**することを試みることができます：_https://example.com/my/dear/api/val/num?**\_method=PUT**_
+アプリケーションは、token が存在する場合にそれを **validate** する仕組みを実装していることがあります。しかし、token が欠落しているときに検証処理を完全にスキップしてしまうと脆弱性が発生します。攻撃者は token の値を変えるだけでなく、token を運んでいる parameter 自体を**削除する**ことでこれを悪用できます。これにより検証を回避し、Cross-Site Request Forgery (CSRF) を効果的に実行できます。
-これは、**POSTリクエスト内に\_methodパラメータを送信する**か、**ヘッダー**を使用することで機能する可能性もあります：
+### CSRF token is not tied to the user session
+
+CSRF tokens を user sessions に紐付けていないアプリケーションは重大な security risk を抱えています。これらのシステムは各トークンを発行元セッションに結び付けるのではなく、global pool に対して検証を行います。
+
+攻撃者がこれを悪用する流れは次の通りです:
+
+1. 自分のアカウントで認証する。
+2. global pool から有効な CSRF token を取得する。
+3. その token を被害者に対する CSRF 攻撃で使用する。
+
+この脆弱性により、攻撃者は被害者になりすまして不正なリクエストを送信でき、アプリケーションの不十分な token validation 機構を悪用できます。
+
+### Method bypass
+
+リクエストが「変わった」method を使用している場合、method override 機能が動作しているか確認してください。例えば PUT を使っている場合、POST を使って以下のように送ることで試せます: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
+
+これは、**\_method parameter を POST リクエスト内に含める**か、次のような headers を使って送ることでも動作する可能性があります:
- _X-HTTP-Method_
- _X-HTTP-Method-Override_
- _X-Method-Override_
-### カスタムヘッダートークンのバイパス
+### Custom header token bypass
-リクエストが**CSRF保護メソッド**として**トークン**を持つ**カスタムヘッダー**を追加している場合：
+リクエストに CSRF protection method として **custom header** に **token** を追加している場合は、次を試してください:
-- **カスタマイズされたトークンとヘッダーなしでリクエストをテスト**します。
-- **同じ長さだが異なるトークンでリクエストをテスト**します。
+- **Customized Token と header の両方を省いた**状態でリクエストをテストする。
+- 同じ長さだが異なる token を使ってリクエストをテストする。
-### CSRFトークンがクッキーによって検証される
+### CSRF token is verified by a cookie
-アプリケーションは、トークンをクッキーとリクエストパラメータの両方に複製することによってCSRF保護を実装するか、CSRFクッキーを設定し、バックエンドで送信されたトークンがクッキーに対応しているかを検証することがあります。アプリケーションは、リクエストパラメータ内のトークンがクッキーの値と一致するかを確認することでリクエストを検証します。
+アプリケーションは、token を cookie とリクエスト parameter の両方に複製するか、CSRF cookie をセットしてバックエンドで送信された token がその cookie に対応しているかを検証することで CSRF 保護を実装することがあります。アプリケーションは、リクエスト parameter の token が cookie の値と一致するかをチェックしてリクエストを検証します。
-しかし、この方法は、攻撃者が被害者のブラウザにCSRFクッキーを設定できる欠陥がある場合、CSRF攻撃に対して脆弱です。攻撃者は、クッキーを設定する欺瞞的な画像を読み込んだ後、CSRF攻撃を開始することでこれを悪用できます。
+しかし、この方法は、攻撃者が被害者のブラウザに CSRF cookie を設定できてしまうような脆弱性（例: CRLF 脆弱性）があると CSRF 攻撃に対して脆弱になります。攻撃者は、まず不正な画像を読み込ませて cookie を設定させ、続けて CSRF 攻撃を開始することでこれを悪用できます。
-以下は、攻撃がどのように構成されるかの例です：
+以下は攻撃の構成例です:
```html
@@ -103,19 +131,19 @@ onerror="document.forms[0].submit();" />
```
> [!TIP]
-> セッションクッキーに**csrfトークンが関連付けられている場合、この攻撃は機能しません**。なぜなら、被害者のセッションを設定する必要があり、そのため自分自身を攻撃することになります。
+> 注意: **csrf token が session cookie に関連している場合、この攻撃は機能しません**。なぜなら被害者の session を設定する必要があり、その結果自分自身を攻撃することになるからです。
### Content-Typeの変更
-[**これ**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests)によると、**POST**メソッドを使用して**プレフライト**リクエストを回避するために、許可されているContent-Typeの値は次のとおりです。
+According to [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), in order to **preflight を回避する** requests using **POST** method these are the allowed Content-Type values:
- **`application/x-www-form-urlencoded`**
- **`multipart/form-data`**
- **`text/plain`**
-ただし、使用される**Content-Type**によって**サーバーのロジックが異なる場合がある**ため、上記の値や**`application/json`**、**`text/xml`**、**`application/xml`**などの他の値も試すべきです。
+However, note that the **サーバのロジックは異なる場合があります** depending on the **Content-Type** used so you should try the values mentioned and others like **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
-例（[こちら](https://brycec.me/posts/corctf_2021_challenges)から）では、JSONデータをtext/plainとして送信しています：
+Example (from [here](https://brycec.me/posts/corctf_2021_challenges)) of sending JSON data as text/plain:
```html
@@ -134,31 +162,32 @@ form.submit()
```
-### JSONデータのプリフライトリクエストをバイパスする
+### JSON データの preflight request の回避
-POSTリクエストを介してJSONデータを送信しようとする際、HTMLフォームで`Content-Type: application/json`を直接使用することはできません。同様に、`XMLHttpRequest`を使用してこのコンテンツタイプを送信すると、プリフライトリクエストが開始されます。それでも、この制限を回避し、サーバーがContent-Typeに関係なくJSONデータを処理するかどうかを確認するための戦略があります：
+POST リクエストで JSON データを送信しようとする場合、HTML フォーム内で `Content-Type: application/json` を直接指定することはできません。同様に、`XMLHttpRequest` を使ってこの Content-Type を送ると preflight request が発生します。それでも、この制約を回避して、サーバが Content-Type に関係なく JSON データを処理するかを確認するための手法はいくつかあります:
-1. **代替コンテンツタイプの使用**: フォームで`enctype="text/plain"`を設定することにより、`Content-Type: text/plain`または`Content-Type: application/x-www-form-urlencoded`を使用します。このアプローチは、バックエンドがContent-Typeに関係なくデータを利用するかどうかをテストします。
-2. **コンテンツタイプの変更**: サーバーがコンテンツをJSONとして認識することを保証しつつプリフライトリクエストを回避するために、`Content-Type: text/plain; application/json`でデータを送信できます。これによりプリフライトリクエストはトリガーされませんが、サーバーが`application/json`を受け入れるように設定されていれば正しく処理される可能性があります。
-3. **SWFフラッシュファイルの利用**: あまり一般的ではありませんが、SWFフラッシュファイルを使用してこのような制限を回避する方法もあります。この技術の詳細については、[this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937)を参照してください。
+1. **代替 Content-Type を使用する**: フォームで `enctype="text/plain"` を設定し、`Content-Type: text/plain` または `Content-Type: application/x-www-form-urlencoded` を使用します。この方法はバックエンドが Content-Type に関係なくデータを使用するかをテストします。
+2. **Content-Type を修正する**: preflight request を発生させずにサーバが内容を JSON と認識するようにするために、データを `Content-Type: text/plain; application/json` で送信できます。これにより preflight request は発生しませんが、サーバが `application/json` を受け入れる設定になっていれば正しく処理される可能性があります。
+3. **SWF Flash ファイルの利用**: あまり一般的ではありませんが、SWF フラッシュファイルを用いてこれらの制限を回避する方法があります。この手法の詳細は [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937) を参照してください。
-### リファラー / オリジンチェックのバイパス
+### Referrer / Origin チェック回避
-**リファラーヘッダーを回避する**
+**Referrer ヘッダを避ける**
-アプリケーションは、'Referer'ヘッダーが存在する場合のみ検証することがあります。このヘッダーをブラウザが送信しないようにするために、次のHTMLメタタグを使用できます：
+アプリケーションは 'Referer' ヘッダが存在する場合にのみ検証することがあります。ブラウザがこのヘッダを送信しないようにするには、次の HTML meta タグを使用します:
```xml
```
-これにより、'Referer' ヘッダーが省略され、一部のアプリケーションでの検証チェックを回避できる可能性があります。
+これにより 'Referer' ヘッダーが省略され、いくつかのアプリケーションでの検証チェックを潜在的に回避できます。
+
+**Regexp bypasses**
-**Regexp バイパス**
{{#ref}}
ssrf-server-side-request-forgery/url-format-bypass.md
{{#endref}}
-Referrer がパラメータ内で送信する URL のサーバーのドメイン名を設定するには、次のようにします:
+パラメータ内に Referrer が送信する URL のサーバーのドメイン名を設定するには、次のようにします:
```html
@@ -187,25 +216,25 @@ document.forms[0].submit()