diff --git a/src/network-services-pentesting/1883-pentesting-mqtt-mosquitto.md b/src/network-services-pentesting/1883-pentesting-mqtt-mosquitto.md
index a6d1f5e0c..8e6802ddb 100644
--- a/src/network-services-pentesting/1883-pentesting-mqtt-mosquitto.md
+++ b/src/network-services-pentesting/1883-pentesting-mqtt-mosquitto.md
@@ -4,7 +4,7 @@
## 基本情報
-**MQ Telemetry Transport (MQTT)** は、極めてシンプルで軽量な **publish/subscribe メッセージングプロトコル** として知られています。このプロトコルは、デバイスの能力が限られている環境や、低帯域幅、高遅延、または信頼性の低い接続が特徴のネットワークでの運用に特化しています。MQTTの主な目的は、ネットワーク帯域幅の使用を最小限に抑え、デバイスリソースへの要求を減らすことです。さらに、信頼性のある通信を維持し、一定の配信保証を提供することを目指しています。これらの目標により、MQTTは急成長している **機械間通信 (M2M)** および **モノのインターネット (IoT)** の分野に非常に適しています。ここでは、多数のデバイスを効率的に接続することが不可欠です。さらに、MQTTはモバイルアプリケーションにとっても非常に有益であり、帯域幅とバッテリー寿命を節約することが重要です。
+**MQ Telemetry Transport (MQTT)** は、極めてシンプルで軽量な **publish/subscribe メッセージングプロトコル** として知られています。このプロトコルは、デバイスの能力が限られている環境や、低帯域幅、高遅延、または信頼性の低い接続が特徴のネットワークで動作するように特別に設計されています。MQTTの主な目的は、ネットワーク帯域幅の使用を最小限に抑え、デバイスリソースへの要求を減らすことです。さらに、信頼性のある通信を維持し、一定の配信保証を提供することを目指しています。これらの目標により、MQTTは急成長している **機械間通信 (M2M)** および **モノのインターネット (IoT)** の分野に非常に適しています。ここでは、多数のデバイスを効率的に接続することが不可欠です。さらに、MQTTはモバイルアプリケーションにも非常に有益であり、帯域幅とバッテリー寿命を節約することが重要です。
**デフォルトポート:** 1883
```
@@ -30,13 +30,15 @@ For instance, if the broker rejects the connection due to invalid credentials, t
**認証は完全にオプションです** そして、認証が行われている場合でも、**デフォルトでは暗号化は使用されません**(資格情報は平文で送信されます)。MITM攻撃は依然として実行可能で、パスワードを盗むことができます。
-MQTTサービスに接続するには、次のものを使用できます: [https://github.com/bapowell/python-mqtt-client-shell](https://github.com/bapowell/python-mqtt-client-shell) そして、次のようにしてすべてのトピックに自分を購読します:
+MQTTサービスに接続するには、[https://github.com/bapowell/python-mqtt-client-shell](https://github.com/bapowell/python-mqtt-client-shell)を使用し、次のようにしてすべてのトピックに自分を購読させることができます:
```
> connect (NOTICE that you need to indicate before this the params of the connection, by default 127.0.0.1:1883)
> subscribe "#" 1
> subscribe "$SYS/#"
```
-あなたは次のものを使用することもできます:
+あなたはまた、[**https://github.com/akamai-threat-research/mqtt-pwn**](https://github.com/akamai-threat-research/mqtt-pwn)を使用することができます。
+
+あなたはまた、次を使用することができます:
```bash
apt-get install mosquitto mosquitto-clients
mosquitto_sub -t 'test/topic' -v #Subscribe to 'test/topic'
@@ -71,28 +73,24 @@ client.loop_start()
if __name__ == "__main__":
main()
```
-## さらなる情報
+### The Publish/Subscribe Pattern
-ここから: [https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b](https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b)
+publish/subscribeモデルは以下で構成されています:
-### パブリッシュ/サブスクライブパターン
+- **Publisher**: ブローカー内の1つ(または複数)のトピックにメッセージを公開します。
+- **Subscriber**: ブローカー内の1つ(または複数)のトピックにサブスクライブし、パブリッシャーから送信されたすべてのメッセージを受信します。
+- **Broker**: パブリッシャーからサブスクライバーへのすべてのメッセージをルーティングします。
+- **Topic**: スラッシュ(例:/smartshouse/livingroom/temperature)で区切られた1つ以上のレベルで構成されています。
-パブリッシュ/サブスクライブモデルは以下で構成されています:
+### Packet Format
-- **パブリッシャー**: ブローカー内の1つ(または複数)のトピックにメッセージを公開します。
-- **サブスクライバー**: ブローカー内の1つ(または複数)のトピックにサブスクライブし、パブリッシャーから送信されたすべてのメッセージを受信します。
-- **ブローカー**: パブリッシャーからサブスクライバーへのすべてのメッセージをルーティングします。
-- **トピック**: スラッシュ(/)で区切られた1つ以上のレベルで構成されています(例: /smartshouse/livingroom/temperature)。
-
-### パケットフォーマット
-
-すべてのMQTTパケットには固定ヘッダーが含まれています(図02)。図02: 固定ヘッダー
+すべてのMQTTパケットは固定ヘッダーを含みます(図02)。図02: 固定ヘッダー

-### パケットタイプ
+### Packet Types
-- CONNECT (1): クライアントがサーバーへの接続を要求するために開始します。
+- CONNECT (1): クライアントによってサーバーへの接続をリクエストするために開始されます。
- CONNACK (2): サーバーの成功した接続の確認。
- PUBLISH (3): クライアントからサーバー、またはその逆にメッセージを送信するために使用されます。
- PUBACK (4): PUBLISHパケットの確認。
@@ -102,11 +100,11 @@ main()
- SUBSCRIBE (8): クライアントがトピックからメッセージを受信するリクエスト。
- SUBACK (9): サーバーのSUBSCRIBEリクエストの確認。
- UNSUBSCRIBE (10): クライアントがトピックからのメッセージ受信を停止するリクエスト。
-- UNSUBACK (11): サーバーのUNSUBSCRIBEリクエストへの応答。
+- UNSUBACK (11): UNSUBSCRIBEリクエストに対するサーバーの応答。
- PINGREQ (12): クライアントによって送信されるハートビートメッセージ。
- PINGRESP (13): ハートビートメッセージに対するサーバーの応答。
- DISCONNECT (14): クライアントによって接続を終了するために開始されます。
-- 0と15の2つの値は予約されており、その使用は禁止されています。
+- 0と15の2つの値は予約されており、その使用は禁じられています。
## Shodan
diff --git a/src/pentesting-web/cache-deception/README.md b/src/pentesting-web/cache-deception/README.md
index 3d937fb39..8bfeb7446 100644
--- a/src/pentesting-web/cache-deception/README.md
+++ b/src/pentesting-web/cache-deception/README.md
@@ -15,17 +15,17 @@
キャッシュポイズニング攻撃の実行にはいくつかのステップがあります:
-1. **キーのない入力の特定**:これらは、リクエストがキャッシュされるために必要ではないパラメータですが、サーバーが返すレスポンスを変更する可能性があります。これらの入力を特定することは重要であり、キャッシュを操作するために悪用される可能性があります。
-2. **キーのない入力の悪用**:キーのない入力を特定した後、次のステップは、攻撃者に利益をもたらす方法でサーバーのレスポンスを変更するためにこれらのパラメータを誤用する方法を見つけることです。
-3. **汚染されたレスポンスがキャッシュされることを確認**:最後のステップは、操作されたレスポンスがキャッシュに保存されることを確認することです。これにより、キャッシュが汚染されている間に影響を受けるページにアクセスするユーザーは、汚染されたレスポンスを受け取ります。
+1. **キーなし入力の特定**:これらは、リクエストがキャッシュされるために必須ではないパラメータですが、サーバーが返すレスポンスを変更する可能性があります。これらの入力を特定することは重要であり、キャッシュを操作するために悪用される可能性があります。
+2. **キーなし入力の悪用**:キーなし入力を特定した後、次のステップは、攻撃者に利益をもたらす方法でサーバーのレスポンスを変更するためにこれらのパラメータをどのように誤用するかを考えることです。
+3. **汚染されたレスポンスがキャッシュされることを確認**:最終ステップは、操作されたレスポンスがキャッシュに保存されることを確認することです。これにより、キャッシュが汚染されている間に影響を受けるページにアクセスするユーザーは、汚染されたレスポンスを受け取ります。
### 発見:HTTPヘッダーを確認
-通常、レスポンスが**キャッシュに保存された**場合、**それを示すヘッダーがあります**。どのヘッダーに注意を払うべきかは、この投稿で確認できます:[**HTTPキャッシュヘッダー**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)。
+通常、レスポンスが**キャッシュに保存された**場合、**それを示すヘッダーがあります**。この投稿で注意すべきヘッダーを確認できます:[**HTTPキャッシュヘッダー**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)。
### 発見:キャッシュエラーコード
-レスポンスがキャッシュに保存されていると考えている場合、**不正なヘッダーでリクエストを送信**してみることができます。これには**ステータスコード400**で応答されるべきです。その後、リクエストに通常アクセスして、**レスポンスが400ステータスコード**であれば、それが脆弱であることがわかります(さらにはDoS攻撃を実行することも可能です)。
+レスポンスがキャッシュに保存されていると考えている場合、**不正なヘッダーでリクエストを送信**してみると良いでしょう。これには**ステータスコード400**で応答されるはずです。その後、リクエストに通常アクセスして、**レスポンスが400ステータスコード**であれば、それが脆弱であることがわかります(DoSを実行することも可能です)。
さらにオプションを見つけることができます:
@@ -35,7 +35,7 @@ cache-poisoning-to-dos.md
ただし、**これらの種類のステータスコードがキャッシュされないこともある**ため、このテストは信頼できない可能性があります。
-### 発見:キーのない入力を特定し評価する
+### 発見:キーなし入力を特定し評価する
[**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943)を使用して、**ページのレスポンスを変更する可能性のあるパラメータやヘッダーをブルートフォース**することができます。たとえば、ページが`X-Forwarded-For`ヘッダーを使用してクライアントにスクリプトをそこから読み込むように指示している場合があります:
```html
@@ -45,18 +45,18 @@ cache-poisoning-to-dos.md
パラメータ/ヘッダーが特定されたら、それがどのように**サニタイズ**されているか、また**どこで**応答に**反映**されているかを確認します。これを悪用することはできますか(XSSを実行する、またはあなたが制御するJSコードを読み込む?DoSを実行する?...)
-### 応答をキャッシュさせる
+### 応答をキャッシュする
-悪用できる**ページ**を**特定**し、使用する**パラメータ**/**ヘッダー**と**どのように**悪用するかが分かったら、そのページをキャッシュさせる必要があります。キャッシュに取得しようとしているリソースによっては、これには時間がかかる場合があり、数秒間試みる必要があるかもしれません。
+悪用できる**ページ**を**特定**し、使用する**パラメータ**/**ヘッダー**と**悪用方法**を決定したら、そのページをキャッシュする必要があります。キャッシュに取得しようとしているリソースによっては、これには時間がかかる場合があり、数秒間試みる必要があるかもしれません。
応答のヘッダー**`X-Cache`**は非常に便利で、リクエストがキャッシュされていない場合は**`miss`**の値を持ち、キャッシュされている場合は**`hit`**の値を持つ可能性があります。\
-ヘッダー**`Cache-Control`**も、リソースがキャッシュされているかどうか、次回そのリソースが再キャッシュされるのはいつかを知るために興味深いです: `Cache-Control: public, max-age=1800`
+ヘッダー**`Cache-Control`**も、リソースがキャッシュされているかどうか、次回リソースが再キャッシュされるのはいつかを知るために興味深いです: `Cache-Control: public, max-age=1800`
-もう一つの興味深いヘッダーは**`Vary`**です。このヘッダーは、通常はキーがない場合でも、**キャッシュキーの一部**として扱われる**追加のヘッダー**を**示すため**に使用されることがよくあります。したがって、ユーザーがターゲットとしている被害者の`User-Agent`を知っている場合、その特定の`User-Agent`を使用するユーザーのためにキャッシュを汚染することができます。
+もう一つの興味深いヘッダーは**`Vary`**です。このヘッダーは、通常はキーがないにもかかわらず、**キャッシュキーの一部**として扱われる**追加ヘッダー**を**示すため**にしばしば使用されます。したがって、ターゲットとしている被害者の`User-Agent`を知っている場合、特定の`User-Agent`を使用するユーザーのためにキャッシュを汚染することができます。
-キャッシュに関連するもう一つのヘッダーは**`Age`**です。これは、オブジェクトがプロキシキャッシュに存在している時間を秒単位で定義します。
+キャッシュに関連するもう一つのヘッダーは**`Age`**です。これは、オブジェクトがプロキシキャッシュに存在している秒数を定義します。
-リクエストをキャッシュする際は、使用するヘッダーに**注意**してください。なぜなら、それらのいくつかは**予期せず**に**キーとして使用される**可能性があり、**被害者はその同じヘッダーを使用する必要がある**からです。常に**異なるブラウザ**でキャッシュポイズニングを**テスト**して、機能しているか確認してください。
+リクエストをキャッシュする際は、使用するヘッダーに**注意**してください。なぜなら、いくつかのヘッダーは**予期せず**に**キー付き**として使用される可能性があり、**被害者はその同じヘッダーを使用する必要がある**からです。常に**異なるブラウザ**でキャッシュポイズニングを**テスト**して、機能しているか確認してください。
## 悪用の例
@@ -77,19 +77,27 @@ _Note that this will poison a request to `/en?region=uk` not to `/en`_
cache-poisoning-to-dos.md
{{#endref}}
+### Cache poisoning through CDNs
+
+**[この書き込み](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** では、以下の単純なシナリオが説明されています:
+
+- CDNは`/share/`以下のすべてをキャッシュします。
+- CDNは`%2F..%2F`をデコードまたは正規化しないため、**他の機密情報にアクセスするためのパストラバーサルとして使用できる**、例えば`https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`のように。
+- ウェブサーバーは`%2F..%2F`をデコードおよび正規化し、`/api/auth/session`で応答します。これには**認証トークン**が含まれています。
+
### Using web cache poisoning to exploit cookie-handling vulnerabilities
-クッキーはページのレスポンスに反映されることもあります。これを悪用してXSSを引き起こすことができれば、悪意のあるキャッシュレスポンスを読み込む複数のクライアントでXSSを利用できる可能性があります。
+クッキーはページの応答に反映されることもあります。これを悪用してXSSを引き起こすことができれば、悪意のあるキャッシュ応答を読み込む複数のクライアントでXSSを利用できる可能性があります。
```html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
-注意してください。脆弱なクッキーがユーザーによって非常に使用されている場合、通常のリクエストがキャッシュをクリアします。
+注意:脆弱なクッキーがユーザーによって非常に使用されている場合、定期的なリクエストがキャッシュをクリアします。
### デリミタ、正規化、ドットを使用して不一致を生成する
-確認してください:
+確認:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
@@ -97,9 +105,9 @@ cache-poisoning-via-url-discrepancies.md
### APIキーを盗むためのパストラバーサルによるキャッシュポイズニング
-[**この解説は**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` のようなURLを使用してOpenAI APIキーを盗むことが可能だった理由を説明しています。`/share/*` に一致するものは、CloudflareがURLを正規化することなくキャッシュされます。これはリクエストがウェブサーバーに到達したときに行われました。
+[**この解説は**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` のようなURLを使用してOpenAI APIキーを盗むことが可能だった理由を説明しています。`/share/*` に一致するものは、リクエストがウェブサーバーに到達したときにCloudflareがURLを正規化することなくキャッシュされます。
-これについては、以下でもより詳しく説明されています:
+これは以下でもより詳しく説明されています:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
@@ -107,7 +115,7 @@ cache-poisoning-via-url-discrepancies.md
### 複数のヘッダーを使用してウェブキャッシュポイズニングの脆弱性を悪用する
-時には、キャッシュを悪用するために**複数のキーなし入力を悪用する必要があります**。例えば、`X-Forwarded-Host`をあなたが管理するドメインに設定し、`X-Forwarded-Scheme`を`http`に設定すると、**オープンリダイレクト**を見つけることができるかもしれません。**もし**サーバーがすべての**HTTP**リクエストを**HTTPS**に**転送**し、リダイレクトのドメイン名としてヘッダー`X-Forwarded-Scheme`を使用している場合、リダイレクトによってページが指す場所を制御できます。
+時には、キャッシュを悪用するために**複数のキーなし入力を悪用する**必要があります。例えば、`X-Forwarded-Host`をあなたが制御するドメインに設定し、`X-Forwarded-Scheme`を`http`に設定すると、**オープンリダイレクト**を見つけることができるかもしれません。**もし**サーバーがすべての**HTTP**リクエストを**HTTPS**に**転送**し、リダイレクトのドメイン名としてヘッダー`X-Forwarded-Scheme`を使用している場合、リダイレクトによってページが指す場所を制御できます。
```html
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
@@ -116,7 +124,7 @@ X-Forwarded-Scheme: http
```
### 限定された `Vary` ヘッダーを利用した攻撃
-もし **`X-Host`** ヘッダーが **JSリソースを読み込むためのドメイン名** として使用されていることがわかり、レスポンスの **`Vary`** ヘッダーが **`User-Agent`** を示している場合、被害者の User-Agent を外部に流出させ、そのユーザーエージェントを使用してキャッシュを汚染する方法を見つける必要があります。
+もし **`X-Host`** ヘッダーが **JSリソースを読み込むためのドメイン名** として使用されているが、レスポンスの **`Vary`** ヘッダーが **`User-Agent`** を示している場合、被害者の User-Agent を抽出し、そのユーザーエージェントを使用してキャッシュを汚染する方法を見つける必要があります。
```html
GET / HTTP/1.1
Host: vulnerbale.net
@@ -125,7 +133,7 @@ X-Host: attacker.com
```
### Fat Get
-URLとボディの両方にリクエストを含むGETリクエストを送信します。ウェブサーバーがボディのものを使用するが、キャッシュサーバーがURLのものをキャッシュする場合、そのURLにアクセスする誰もが実際にはボディのパラメータを使用します。James KettleがGithubウェブサイトで発見した脆弱性のように:
+URLとボディの両方にリクエストを含むGETリクエストを送信します。ウェブサーバーがボディのものを使用するが、キャッシュサーバーがURLのものをキャッシュする場合、そのURLにアクセスする誰もが実際にはボディからのパラメータを使用します。James KettleがGithubウェブサイトで見つけた脆弱性のように:
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
@@ -136,17 +144,17 @@ report=innocent-victim
```
There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
-### パラメータクロッキング
+### パラメータクラッキング
-例えば、**パラメータ**をrubyサーバーで**`;`**の文字を使って**`&`**の代わりに分けることが可能です。これを利用して、キーのないパラメータの値をキーのあるものの中に入れ、悪用することができます。
+例えば、**パラメータ**を**`&`**の代わりに**`;`**文字を使用してrubyサーバーで分離することが可能です。これを利用して、キーのないパラメータの値をキーのあるものの中に入れ込み、悪用することができます。
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
### HTTPキャッシュポイズニングの悪用
-[Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)の実行方法について学びましょう。
+[Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)の実施方法について学びましょう。
-### Webキャッシュポイズニングの自動テスト
+### Web Cache Poisoningの自動テスト
[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)を使用して、Webキャッシュポイズニングを自動的にテストできます。多くの異なる技術をサポートしており、高度にカスタマイズ可能です。
@@ -156,7 +164,7 @@ Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/explo
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
-ATSはURL内のフラグメントを削除せずに転送し、キャッシュキーをホスト、パス、クエリのみを使用して生成しました(フラグメントは無視されます)。そのため、リクエスト`/#/../?r=javascript:alert(1)`はバックエンドに`/#/../?r=javascript:alert(1)`として送信され、キャッシュキーにはペイロードが含まれておらず、ホスト、パス、クエリのみでした。
+ATSはURL内のフラグメントを削除せずに転送し、ホスト、パス、クエリのみを使用してキャッシュキーを生成しました(フラグメントは無視されます)。そのため、リクエスト`/#/../?r=javascript:alert(1)`はバックエンドに`/#/../?r=javascript:alert(1)`として送信され、キャッシュキーにはペイロードが含まれておらず、ホスト、パス、クエリのみが含まれていました。
### GitHub CP-DoS
@@ -166,9 +174,9 @@ content-typeヘッダーに不正な値を送信すると、405キャッシュ
GitLabは静的コンテンツを保存するためにGCPバケットを使用しています。**GCPバケット**は**ヘッダー`x-http-method-override`**をサポートしています。したがって、ヘッダー`x-http-method-override: HEAD`を送信し、キャッシュを毒して空のレスポンスボディを返すことが可能でした。また、`PURGE`メソッドもサポートされていました。
-### Rackミドルウェア(Ruby on Rails)
+### Rack Middleware (Ruby on Rails)
-Ruby on Railsアプリケーションでは、Rackミドルウェアがよく利用されます。Rackコードの目的は、**`x-forwarded-scheme`**ヘッダーの値を取得し、それをリクエストのスキームとして設定することです。ヘッダー`x-forwarded-scheme: http`が送信されると、同じ場所への301リダイレクトが発生し、そのリソースに対してサービス拒否(DoS)を引き起こす可能性があります。さらに、アプリケーションは`X-forwarded-host`ヘッダーを認識し、指定されたホストにユーザーをリダイレクトする可能性があります。この動作により、攻撃者のサーバーからJavaScriptファイルが読み込まれることになり、セキュリティリスクが生じます。
+Ruby on Railsアプリケーションでは、Rackミドルウェアがよく利用されます。Rackコードの目的は、**`x-forwarded-scheme`**ヘッダーの値を取得し、それをリクエストのスキームとして設定することです。ヘッダー`x-forwarded-scheme: http`が送信されると、同じ場所への301リダイレクトが発生し、そのリソースに対してサービス拒否(DoS)を引き起こす可能性があります。さらに、アプリケーションは`X-forwarded-host`ヘッダーを認識し、指定されたホストにユーザーをリダイレクトする可能性があります。この動作により、攻撃者のサーバーからJavaScriptファイルが読み込まれ、セキュリティリスクが生じる可能性があります。
### 403とストレージバケット
@@ -176,15 +184,15 @@ Cloudflareは以前、403レスポンスをキャッシュしていました。
### キー付きパラメータの注入
-キャッシュはしばしばキャッシュキーに特定のGETパラメータを含めます。例えば、FastlyのVarnishはリクエストの`size`パラメータをキャッシュしました。しかし、パラメータのURLエンコードされたバージョン(例:`siz%65`)が誤った値で送信された場合、キャッシュキーは正しい`size`パラメータを使用して構築されます。しかし、バックエンドはURLエンコードされたパラメータの値を処理します。2番目の`size`パラメータをURLエンコードすると、キャッシュによって省略されますが、バックエンドによって利用されます。このパラメータに0の値を割り当てると、キャッシュ可能な400 Bad Requestエラーが発生しました。
+キャッシュはしばしばキャッシュキーに特定のGETパラメータを含めます。例えば、FastlyのVarnishはリクエストの`size`パラメータをキャッシュしました。しかし、パラメータのURLエンコードされたバージョン(例:`siz%65`)が誤った値で送信された場合、キャッシュキーは正しい`size`パラメータを使用して構築されます。しかし、バックエンドはURLエンコードされたパラメータの値を処理します。2番目の`size`パラメータをURLエンコードすると、キャッシュによって省略されますが、バックエンドによって利用されます。このパラメータに0の値を割り当てると、キャッシュ可能な400 Bad Requestエラーが発生しました。
### ユーザーエージェントルール
-一部の開発者は、FFUFやNucleiのような高トラフィックツールのユーザーエージェントに一致するリクエストをブロックしてサーバーの負荷を管理します。皮肉なことに、このアプローチはキャッシュポイズニングやDoSなどの脆弱性を引き起こす可能性があります。
+一部の開発者は、サーバーの負荷を管理するために、FFUFやNucleiなどの高トラフィックツールのユーザーエージェントに一致するリクエストをブロックします。皮肉なことに、このアプローチはキャッシュポイズニングやDoSなどの脆弱性を引き起こす可能性があります。
### 不正なヘッダーフィールド
-[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230)は、ヘッダー名に許可される文字を指定しています。指定された**tchar**範囲外の文字を含むヘッダーは、理想的には400 Bad Requestレスポンスをトリガーするべきです。実際には、サーバーは常にこの標準に従うわけではありません。特に注目すべき例は、Akamaiが無効な文字を含むヘッダーを転送し、`cache-control`ヘッダーが存在しない限り、400エラーをキャッシュすることです。不正な文字(例:`\`)を含むヘッダーを送信すると、キャッシュ可能な400 Bad Requestエラーが発生するという悪用可能なパターンが特定されました。
+[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230)は、ヘッダー名における許可される文字を指定しています。指定された**tchar**範囲外の文字を含むヘッダーは、理想的には400 Bad Requestレスポンスをトリガーするべきです。実際には、サーバーはこの標準に常に従うわけではありません。特に注目すべき例は、Akamaiが無効な文字を含むヘッダーを転送し、`cache-control`ヘッダーが存在しない限り、400エラーをキャッシュすることです。不正な文字(例:`\`)を含むヘッダーを送信すると、キャッシュ可能な400 Bad Requestエラーが発生するという悪用可能なパターンが特定されました。
### 新しいヘッダーの発見
@@ -192,26 +200,26 @@ Cloudflareは以前、403レスポンスをキャッシュしていました。
## キャッシュデセプション
-キャッシュデセプションの目的は、クライアントに**キャッシュによって保存されるリソースをその機密情報と共に読み込ませる**ことです。
+キャッシュデセプションの目的は、クライアントに**機密情報を持つリソースをキャッシュに保存させること**です。
-まず、**拡張子**(例:`.css`、`.js`、`.png`など)が通常**キャッシュに保存される**ように**設定されている**ことに注意してください。したがって、`www.example.com/profile.php/nonexistent.js`にアクセスすると、キャッシュはおそらくレスポンスを保存します。なぜなら、`.js`の**拡張子**を見ているからです。しかし、**アプリケーション**が_ www.example.com/profile.php_に保存された**機密**ユーザーコンテンツで**再生**している場合、他のユーザーからそのコンテンツを**盗む**ことができます。
+まず、**拡張子**(例:`.css`、`.js`、`.png`など)が通常**キャッシュに保存されるように**設定されていることに注意してください。したがって、`www.example.com/profile.php/nonexistent.js`にアクセスすると、キャッシュはおそらく`.js`**拡張子**を見てレスポンスを保存します。しかし、**アプリケーション**が_ www.example.com/profile.php_に保存された**機密**ユーザーコンテンツで**再生**している場合、他のユーザーからそのコンテンツを**盗む**ことができます。
-他にテストすること:
+他にテストするべきこと:
- _www.example.com/profile.php/.js_
- _www.example.com/profile.php/.css_
- _www.example.com/profile.php/test.js_
- _www.example.com/profile.php/../test.js_
- _www.example.com/profile.php/%2e%2e/test.js_
-- _あまり知られていない拡張子を使用する(例:`.avif`)_
+- _あまり知られていない拡張子(例:`.avif`)を使用する_
-非常に明確な例は、この書き込みに見つけることができます: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)。\
+非常に明確な別の例は、この書き込みに見つけることができます: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)。\
この例では、_http://www.example.com/home.php/non-existent.css_のような存在しないページを読み込むと、_http://www.example.com/home.php_(**ユーザーの機密情報を含む**)の内容が返され、キャッシュサーバーが結果を保存することが説明されています。\
その後、**攻撃者**は自分のブラウザで_http://www.example.com/home.php/non-existent.css_にアクセスし、以前にアクセスしたユーザーの**機密情報**を観察できます。
**キャッシュプロキシ**は、ファイルの**拡張子**(_.css_)に基づいてファイルを**キャッシュ**するように**設定**されるべきであり、コンテンツタイプに基づいてはなりません。例として_http://www.example.com/home.php/non-existent.css_は、_.css_ファイルに期待される`text/css` MIMEタイプの代わりに`text/html`コンテンツタイプを持ちます。
-[Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception)の実行方法について学びましょう。
+[Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception)の実施方法について学びましょう。
## 自動ツール
diff --git a/src/pentesting-web/hacking-with-cookies/cookie-tossing.md b/src/pentesting-web/hacking-with-cookies/cookie-tossing.md
index cbd65af55..8cdafcdb2 100644
--- a/src/pentesting-web/hacking-with-cookies/cookie-tossing.md
+++ b/src/pentesting-web/hacking-with-cookies/cookie-tossing.md
@@ -13,22 +13,23 @@ Cookies Hackingセクションで示されたように、**クッキーがドメ
これは危険であり、攻撃者は次のことができるかもしれません:
-- **被害者のクッキーを攻撃者のアカウントに固定する**ので、ユーザーが気づかない場合、**攻撃者のアカウントでアクションを実行します**。攻撃者は興味深い情報を取得できるかもしれません(プラットフォームでのユーザーの検索履歴を確認する、被害者がアカウントにクレジットカードを設定する...)。
+- **被害者のクッキーを攻撃者のアカウントに固定する**ことができるため、ユーザーが気づかない場合、**攻撃者のアカウントでアクションを実行します**。攻撃者は興味深い情報を取得できるかもしれません(プラットフォームでのユーザーの検索履歴を確認する、被害者がアカウントにクレジットカードを設定する...)。
+- この[例はこちらにあります](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/)、攻撃者が被害者が**gitリポジトリへのアクセスを認証するために使用する特定のセクションに自分のクッキーを設定した**ため、攻撃者のアカウントからアクセスされます。
- **クッキーがログイン後に変更されない場合**、攻撃者は単に**クッキーを固定(セッション固定)**し、被害者がログインするのを待ってから**そのクッキーを使用して被害者としてログインします**。
- 時には、セッションクッキーが変更されても、攻撃者は以前のものを使用し、新しいものも受け取ります。
-- **クッキーが初期値を設定している場合**(Flaskのように、**クッキー**が**セッションのCSRFトークン**を**設定**し、この値が被害者がログインした後も保持される場合)、**攻撃者はこの既知の値を設定し、それを悪用することができます**(そのシナリオでは、攻撃者はCSRFトークンを知っているため、ユーザーにCSRFリクエストを実行させることができます)。
+- **クッキーが初期値を設定している場合**(flaskのように、**クッキー**が**セッションのCSRFトークン**を**設定することができ、この値は被害者がログインした後も保持される)、**攻撃者はこの既知の値を設定し、その後悪用することができます**(そのシナリオでは、攻撃者はユーザーにCSRFリクエストを実行させることができます)。
- 値を設定するのと同様に、攻撃者はサーバーによって生成された認証されていないクッキーを取得し、そこからCSRFトークンを取得して使用することもできます。
### クッキーの順序
ブラウザが同じ名前の2つのクッキーを受け取ると、**同じスコープ(ドメイン、サブドメイン、パス)に部分的に影響を与える**場合、**ブラウザはリクエストに対して両方のクッキーの値を送信します**。
-どちらが**最も特定のパス**を持っているか、またはどちらが**古いもの**であるかに応じて、ブラウザは**最初にクッキーの値を設定し**、次に他の値を設定します。例:`Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`
+どちらが**最も特定のパス**を持っているか、またはどちらが**古いもの**であるかに応じて、ブラウザは**最初にクッキーの値を設定し**、次に他のクッキーの値を設定します。例:`Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;`
ほとんどの**ウェブサイトは最初の値のみを使用します**。したがって、攻撃者がクッキーを設定したい場合は、別のクッキーが設定される前に設定するか、より特定のパスで設定する方が良いです。
> [!WARNING]
-> さらに、**より特定のパスにクッキーを設定する能力**は非常に興味深いものであり、**被害者がそのクッキーで作業することができるのは、悪意のあるクッキーが設定された特定のパスを除いて、先に送信されることになります**。
+> さらに、**より特定のパスにクッキーを設定する能力**は非常に興味深いものであり、**被害者が自分のクッキーを使用することができるようにし、悪意のあるクッキーが設定された特定のパスではそのクッキーが先に送信される**ことになります。
### 保護バイパス
@@ -40,7 +41,7 @@ Cookies Hackingセクションで示されたように、**クッキーがドメ
cookie-jar-overflow.md
{{#endref}}
-もう一つの有用な**バイパス**は、**クッキーの名前をURLエンコードすること**です。いくつかの保護は、リクエスト内の同じ名前の2つのクッキーをチェックし、その後サーバーはクッキーの名前をデコードします。
+別の有用な**バイパス**は、**クッキーの名前をURLエンコードすること**です。いくつかの保護は、リクエスト内の同じ名前の2つのクッキーをチェックし、その後サーバーはクッキーの名前をデコードします。
### クッキーボム
@@ -54,8 +55,8 @@ cookie-bomb.md
#### **クッキー名にプレフィックス`__Host`を使用する**
-- クッキー名にこのプレフィックスがある場合、**Secureとしてマークされ、セキュアなオリジンから送信され、Domain属性を含まず、Path属性が/に設定されている場合にのみ**Set-Cookieディレクティブで受け入れられます。
-- **これにより、サブドメインがクッキーを頂点ドメインに強制することが防止されます。これらのクッキーは「ドメインロック」されたものと見なされる可能性があります。**
+- クッキー名にこのプレフィックスがある場合、**Secureとしてマークされ、セキュアなオリジンから送信され、Domain属性を含まず、Path属性が/に設定されている場合にのみ**Set-Cookieディレクティブで**受け入れられます**。
+- **これにより、サブドメインがクッキーを頂点ドメインに強制することを防ぎます。これらのクッキーは「ドメインロック」されたものと見なされる可能性があります。**
### 参考文献
diff --git a/src/pentesting-web/xss-cross-site-scripting/README.md b/src/pentesting-web/xss-cross-site-scripting/README.md
index 529e6afcb..9928a2664 100644
--- a/src/pentesting-web/xss-cross-site-scripting/README.md
+++ b/src/pentesting-web/xss-cross-site-scripting/README.md
@@ -3,21 +3,21 @@
## 方法論
1. **あなたが制御する任意の値** (_パラメータ_、_パス_、_ヘッダー_?、_クッキー_?) がHTMLに**反映**されているか、**JS**コードで**使用**されているかを確認します。
-2. **反映されている/使用されているコンテキスト**を見つけます。
+2. **反映されている/使用されているコンテキストを見つけます**。
3. **反映されている場合**
-1. **使用できる記号**を確認し、それに応じてペイロードを準備します:
+1. **使用できる記号を確認**し、それに応じてペイロードを準備します:
1. **生のHTML**内で:
1. 新しいHTMLタグを作成できますか?
2. `javascript:`プロトコルをサポートするイベントや属性を使用できますか?
3. 保護を回避できますか?
4. HTMLコンテンツがクライアントサイドのJSエンジン (_AngularJS_、_VueJS_、_Mavo_...) によって解釈されている場合、[**クライアントサイドテンプレートインジェクション**](../client-side-template-injection-csti.md)を悪用できるかもしれません。
5. JSコードを実行するHTMLタグを作成できない場合、[**ダングリングマークアップ - HTMLスクリプトレスインジェクション**](../dangling-markup-html-scriptless-injection/index.html)を悪用できるかもしれません。
-2. **HTMLタグ内**で:
+2. **HTMLタグ内で**:
1. 生のHTMLコンテキストに抜け出せますか?
-2. JSコードを実行する新しいイベント/属性を作成できますか?
+2. JSコードを実行するための新しいイベント/属性を作成できますか?
3. あなたが閉じ込められている属性はJS実行をサポートしていますか?
4. 保護を回避できますか?
-3. **JavaScriptコード内**で:
+3. **JavaScriptコード内で**:
1. ``**タグの間、`.js`ファイルの中、または**`javascript:`**プロトコルを使用した属性の中に反映されます:
+この場合、あなたの入力はHTMLページの**``**タグ、`.js`ファイル内、または**`javascript:`**プロトコルを使用した属性内に反映されます:
-- **``**タグの間に反映されている場合、たとえあなたの入力がどんな種類の引用符の中にあっても、``を注入してこのコンテキストから**脱出**しようとすることができます。これは、**ブラウザが最初にHTMLタグを解析**し、その後にコンテンツを解析するため、あなたが注入した``タグがHTMLコードの中にあることに気づかないからです。
-- **JS文字列の中**に反映されていて、最後のトリックが機能しない場合は、文字列から**退出**し、コードを**実行**し、JSコードを**再構築**する必要があります(エラーがある場合は実行されません):
+- **``**タグの間に反映されている場合、たとえあなたの入力がどんな種類の引用符の中にあっても、``を注入してこのコンテキストから**脱出**しようとすることができます。これは、**ブラウザが最初にHTMLタグを解析**し、その後にコンテンツを解析するため、あなたが注入した``タグがHTMLコード内にあることに気づかないからです。
+- **JS文字列内**に反映されていて、最後のトリックが機能しない場合は、文字列から**退出**し、**コードを実行**し、JSコードを**再構築**する必要があります(エラーがある場合は実行されません):
- `'-alert(1)-'`
- `';-alert(1)//`
- `\';alert(1)//`
-- テンプレートリテラルの中に反映されている場合、`${ ... }`構文を使用して**JS式を埋め込む**ことができます: `` var greetings = `Hello, ${alert(1)}` ``
+- テンプレートリテラル内に反映されている場合、`${ ... }`構文を使用して**JS式を埋め込む**ことができます: `` var greetings = `Hello, ${alert(1)}` ``
- **Unicodeエンコード**は**有効なjavascriptコード**を書くために機能します:
```javascript
alert(1)
@@ -83,8 +83,8 @@ alert(1)
```
#### Javascript Hoisting
-Javascript Hoistingは、**関数、変数、またはクラスを使用した後に宣言する機会を指し、未宣言の変数や関数を使用するXSSのシナリオを悪用することができます。**\
-**詳細については、以下のページを確認してください:**
+Javascript Hoistingは、**関数、変数、またはクラスを使用した後に宣言する機会を指し、未宣言の変数や関数を使用するXSSのシナリオを悪用できるようにします。**\
+**詳細については、次のページを確認してください:**
{{#ref}}
js-hoisting.md
@@ -92,15 +92,15 @@ js-hoisting.md
### Javascript Function
-いくつかのウェブページには、**実行する関数の名前をパラメータとして受け入れるエンドポイントがあります。** 実際に見られる一般的な例は、`?callback=callbackFunc`のようなものです。
+いくつかのウェブページには、**実行する関数の名前をパラメータとして受け入れるエンドポイントがあります**。一般的な例として、`?callback=callbackFunc`のようなものがあります。
ユーザーによって直接提供された何かが実行されようとしているかどうかを確認する良い方法は、**パラメータの値を変更すること**(例えば「Vulnerable」に)で、コンソールで次のようなエラーを探すことです:
.png>)
-もし脆弱であれば、**値を送信するだけでアラートをトリガーできる可能性があります: **`?callback=alert(1)`**。ただし、これらのエンドポイントは、**内容を検証して、文字、数字、ドット、アンダースコアのみを許可することが非常に一般的です(**`[\w\._]`**)。**
+脆弱であれば、**値を送信するだけでアラートをトリガーできる可能性があります**: **`?callback=alert(1)`**。ただし、これらのエンドポイントは、**コンテンツを検証して、文字、数字、ドット、アンダースコアのみを許可することが非常に一般的です**(**`[\w\._]`**)。
-しかし、その制限があっても、いくつかのアクションを実行することはまだ可能です。これは、有効な文字を使用して**DOM内の任意の要素にアクセスできるためです**:
+しかし、その制限があっても、いくつかのアクションを実行することは依然として可能です。これは、有効な文字を使用して**DOM内の任意の要素にアクセスできるためです**:
.png>)
@@ -124,7 +124,7 @@ some-same-origin-method-execution.md
### DOM
-**JSコード**が、攻撃者によって制御される**データ**を**安全でない方法**で使用しています。例えば、`location.href`。攻撃者は、これを悪用して任意のJSコードを実行することができます。
+**JSコード**が、攻撃者によって制御される**データ**を**安全でない方法で**使用しています。例えば、`location.href`。攻撃者は、これを悪用して任意のJSコードを実行することができます。
{{#ref}}
dom-xss.md
@@ -132,7 +132,7 @@ dom-xss.md
### **ユニバーサルXSS**
-この種のXSSは**どこにでも**見つけることができます。これは、Webアプリケーションのクライアントの悪用だけでなく、**あらゆる** **コンテキスト**に依存します。この種の**任意のJavaScript実行**は、**RCE**を取得したり、クライアントやサーバーの**任意のファイルを読み取ったり**するために悪用されることさえあります。\
+この種のXSSは**どこにでも**見つけることができます。これは、Webアプリケーションのクライアントの悪用だけでなく、**あらゆる****コンテキスト**に依存します。この種の**任意のJavaScript実行**は、**RCE**を取得したり、クライアントやサーバーの**任意のファイルを読み取ったり**するために悪用されることさえあります。\
いくつかの**例**:
{{#ref}}
@@ -149,7 +149,7 @@ server-side-xss-dynamic-pdf.md
## 生のHTML内に注入
-あなたの入力が**HTMLページ内に反映される**場合、またはこのコンテキストでHTMLコードをエスケープして注入できる場合、最初に行うべきことは、`<`を悪用して新しいタグを作成できるかどうかを確認することです: その**文字**を**反映**させて、それが**HTMLエンコード**されているか、**削除**されているか、または**変更なしで反映**されているかを確認してください。**最後のケースでのみ、このケースを悪用できるでしょう**。\
+あなたの入力が**HTMLページ内に反映される**場合、またはこのコンテキストでHTMLコードをエスケープして注入できる場合、最初に行うべきことは、`<`を悪用して新しいタグを作成できるかどうかを確認することです: その**文字**を**反映**させて、**HTMLエンコード**されているか、**削除**されているか、または**変更なしで反映されているか**を確認してください。**最後のケースでのみ、このケースを悪用できるでしょう**。\
この場合も、[**クライアントサイドテンプレートインジェクション**](../client-side-template-injection-csti.md)**を念頭に置いてください。**\
_**注: HTMLコメントは、`-->`または`--!>`を使用して閉じることができます。**_
@@ -162,7 +162,7 @@ alert(1)