CRLF Injection: 攻撃と防御 📝

HTTPヘッダーに潜む静かな脅威の理解

ウェブアプリケーションのセキュリティの複雑な世界において、CRLF injectionは特に巧妙な脆弱性の一つです。これはHTTP通信の基本構造を悪用し、キャリッジリターンとラインフィード文字を操作する攻撃です。この攻撃により、攻撃者はレスポンスの整合性を損ない、ログを汚染し、重要なセキュリティ制御を回避することが可能です。最近の脆弱性には、GFI KerioControlファイアウォールのCVE-2024-52875やCisco Secure ClientのCVE-2024-20337があり、2025年もCRLF injectionの脅威は依然として存在しています。

CRLF injectionとは何か？

CRLF injectionは、攻撃者がユーザー入力にCarriage Return（CR、ASCII 13、\r）とLine Feed（LF、ASCII 10、\n）文字を成功裏に挿入し、それがウェブアプリケーションによって処理されるときに発生する脆弱性です。これらの特殊文字は、さまざまなOSやインターネットプロトコル（特にHTTP）において行末（EOL）を示すマーカーとして機能します。

HTTPプロトコルは、サーバーとクライアント間の通信を構築するためにCRLFシーケンスを利用します。ヘッダーは単一のCRLFシーケンスで区切られ、二重のCRLF（連続した二つのシーケンス）はHTTPヘッダーとメッセージ本文の境界を示します。アプリケーションがこれらの文字を含むユーザー入力を適切にサニタイズしない場合、攻撃者はHTTPレスポンスやログ、その他のテキストストリームの構造を操作できます。

CRLF文字の構造

技術的には: - Carriage Return (CR): \rまたはURLエンコーディングの%0D、カーソルを行の先頭に移動 - Line Feed (LF): \nまたは%0A、カーソルを次の行に移動 - CRLFシーケンス: \r\nまたは%0D%0Aの組み合わせで完全な行終端を作成

これらの文字はOSによって扱いが異なります。WindowsはCRとLF（\r\n）の両方を行末の表現に使いますが、LinuxやUnixはLF（\n）のみを使用します。ただし、HTTP仕様は一貫してCRLFシーケンスを行末に要求しており、Web通信の標準となっています。

CRLF injection攻撃の仕組み

この攻撃の仕組みは非常に単純ながら効果的です。ウェブアプリケーションがユーザー入力を受け取り、それをHTTPヘッダーやログファイルに無検証で組み込むときに、CRLFシーケンスを挿入してアプリケーションの動作を操作します。

攻撃の流れ

例として、リダイレクトパラメータを受け付ける脆弱なウェブアプリを考えます:

http://example.com/redirect?url=http://legitimate-site.com

もしアプリが入力をサニタイズしない場合、攻撃者は悪意のあるURLを作成できます:

http://example.com/redirect?url=http://evil.com%0D%0ASet-Cookie:%20sessionid=attacker_value

サーバーがこのリクエストを処理すると、挿入されたCRLF文字によりHTTPレスポンスは次のように構造化されます:

HTTP/1.1 302 Found
Location: http://evil.com
Set-Cookie: sessionid=attacker_value

サーバーはこの内容を正当なHTTPヘッダーとして解釈し、ユーザセッションの乗っ取りやさらなる攻撃を可能にします。

主な攻撃ベクトル

1. HTTPレスポンススプリッティング

HTTPレスポンススプリッティングは、CRLF injectionの中でも最も危険な攻撃です。この攻撃では、攻撃者が完全なHTTPレスポンスを出力に挿入し、一つのサーバー応答から二つのレスポンスを生成します。

攻撃は段階的に進行します。まず、脆弱なパラメータを特定し、そのパラメータがHTTPヘッダーに反映されることを確認します。次に、二重のCRLFシーケンスを挿入して最初のレスポンスを早期に終了させ、攻撃者の制御下にある二つ目のレスポンスを作成します。

例として、以下のようなペイロードが考えられます:

?page=foobar%0D%0AContent-Length:%200%0D%0A%0D%0AHTTP/1.1%20200%20OK%0D%0AContent-Type:%20text/html%0D%0AContent-Length:%2019%0D%0A%0D%0AhtmlAttack/html

これにより、サーバーは二つの正当なレスポンスを返しているように見えます。最初はContent-Lengthがゼロで早期に終了し、二つ目は攻撃者が制御する内容を含み、中間サーバやキャッシュに保存される可能性があります。

2. ログインジェクションとポイゾニング

ログインジェクションは、HTTPレスポンスではなくアプリケーションのログシステムをターゲットにしたCRLFの悪用です。ユーザー入力を適切にサニタイズしない場合、攻撃者は偽のログエントリを挿入し、追跡を隠したり、無実の第三者を陥れたり、虚偽の監査記録を作成したりできます。

例として、失敗したログイン試行を記録するシナリオ:

2025-11-18 10:45:23 - ユーザ: legitimate_userのログイン失敗

攻撃者は、ユーザ名フィールドにCRLF文字を挿入できます:

attacker%0D%0A2025-11-18%2010:45:23%20-%20成功したログイン:%20admin%0D%0A2025-11-18%2010:45:24%20-%20ログイン失敗:%20

これにより、偽のログエントリが正当なもののように見え、調査を誤導したり、実際の侵害を隠蔽したりします。

3. ヘッダーインジェクションによるクロスサイトスクリプティング（XSS）

CRLF injectionは、攻撃者がHTTPレスポンス本文に悪意のあるJavaScriptを挿入することで、クロスサイトスクリプティング（XSS）にエスカレートする可能性があります。ヘッダーを早期に終了させ、スクリプトコンテンツを挿入することで、攻撃者は被害者のブラウザ内で任意のコードを実行できます。

この攻撃は、二重のCRLFシーケンスがヘッダーの終了とレスポンス本文の開始を示すために機能します。攻撃者は次のような内容を挿入することがあります:

%0D%0AContent-Length:%2035%0D%0A%0D%0Ascriptalert('XSS')/script

現代のブラウザは、この挿入された内容を正当なレスポンスの一部として処理し、悪意のあるスクリプトを実行します。

4. Cookieインジェクションとセッション固定

CRLF injectionは、Cookieの操作を通じてセッションハイジャックを高度に行うことも可能です。攻撃者はSet-Cookieヘッダーを挿入し、事前に決められたセッションIDを設定させることで、セッション固定攻撃を仕掛けます。

例として、URLに挿入されたクッキー:

?redirect=/home%0D%0ASet-Cookie:%20sessionid=attacker_controlled_value;%20Path=/;%20HttpOnly

被害者がこのリンクをクリックすると、サーバーのレスポンスに挿入されたクッキーがブラウザに保存され、その後のログイン時に攻撃者が知っているセッションIDを使用してセッションを乗っ取ることが可能になります。

5. セキュリティ制御の回避

最も懸念されるのは、CRLF injectionがCORSポリシーやCSP、XSSフィルターなどのセキュリティメカニズムを回避できる点です。

攻撃者は、次のような緩いCORSヘッダーを挿入できます:

%0D%0AAccess-Control-Allow-Origin:%20*%0D%0AAccess-Control-Allow-Credentials:%20true

これにより、攻撃者が制御するドメインからのJavaScriptが、同一オリジンポリシーに保護されたリソースにアクセスできるようになり、認証トークンや個人データなどの機密情報が漏洩する危険性があります。

実世界の脆弱性と影響

CVE-2024-52875: GFI KerioControlの重大なRCE

2025年1月、研究者はGFI KerioControlファイアウォールのバージョン9.2.5から9.4.5に影響する重大なCRLF injection脆弱性を公開しました。この脆弱性は、dest GETパラメータの不適切なサニタイズに起因し、攻撃者がLocationヘッダーに改行文字を挿入できるものでした。

この脆弱性の悪用は非常に深刻で、管理者がクリックした悪意のあるURLによりHTTPレスポンススプリッティングが誘発され、クロスサイトスクリプティングに発展、その後マルウェアのアップロードやファイアウォールのrootアクセスを可能にしました。世界中で23,800以上のインターネット公開インスタンスに影響し、企業ネットワークの安全に大きな脅威となりました。

CVE-2024-20337: Cisco Secure ClientのSAML認証

Ciscoは、Secure ClientのSAML認証プロセスにおけるCRLF injection脆弱性を公開しました。この脆弱性により、認証されていないリモート攻撃者が、VPNセッション確立中に巧妙なリンクをクリックさせることで攻撃を仕掛けることが可能でした。

成功すれば、攻撃者はブラウザ内で任意のスクリプトを実行したり、有効なSAMLトークンにアクセスしたりでき、これを用いてリモートアクセスVPNセッションを確立し、影響を受けたユーザの権限でネットワークに侵入できます。

歴史的背景：Twitterや業界全体への影響

過去には、Twitterの広告エンドポイントなど主要プラットフォームでCRLF injectionの脆弱性が発見されています。これらの実例は、リソースの豊富な組織でも、入力検証の不備によりCRLF injectionに陥る可能性があることを示しています。

この脆弱性はBugcrowdのVulnerability Rating Taxonomyで中程度（P3）の深刻度と評価されていますが、KerioControlのケースのようにリモートコード実行にエスカレーションする可能性もあり、リスクは非常に高まります。

CRLFを利用したWebキャッシュポイゾニング

Webキャッシュポイゾニングは、CRLF injectionを利用してCDNやプロキシサーバ、ブラウザキャッシュを汚染する高度な攻撃技術です。

この攻撃は、キャッシュシステムがレスポンスを保存・提供する仕組みを悪用します。攻撃者が悪意のあるレスポンスをキャッシュさせることに成功すれば、その後に同じリソースをリクエストしたユーザは汚染された内容を受け取ることになります。これにより、攻撃の影響範囲は個別のユーザから全体のユーザ群に拡大します。

成功させるには: 1. CRLF脆弱性のあるキャッシュ可能なエンドポイントを特定 2. 悪意のあるレスポンスを挿入できるリクエストを作成 3. そのレスポンスをキャッシュに保存させるタイミングを調整 4. 汚染されたキャッシュから次のユーザに悪意のある内容を提供

キャッシュの永続性により、この攻撃は非常に破壊的です。キャッシュが期限切れになるか手動でクリアされるまで、悪意のあるコンテンツは継続して影響を及ぼします。

検出とテスト手法

手動テスト

セキュリティ研究者やペネトレーションテスターは、体系的なテストを通じてCRLF injectionの脆弱性を特定します。さまざまなCRLFシーケンスをユーザー制御可能なパラメータに挿入し、アプリケーションの挙動を観察します。

一般的なペイロード例: - %0D%0A（URLエンコードされたCRLF） - %0Dや%0A（個別のコンポーネント） - %0D%0ASet-Cookie: test=value - %0D%0A%0D%0Ahtmltest/html（レスポンススプリッティング用の二重CRLF） - Unicodeバリエーション: %E5%98%8A%E5%98%8D

ヘッダーに影響を与えるパラメータに注目します: - リダイレクトパラメータ（url, redirect, dest, return） - リファラー値 - User-Agentの変更 - Cookieの名前と値 - カスタムヘッダー

自動スキャンツール

現代のセキュリティテストには、CRLF injectionを検出するための専用ツールが利用されています:

CRLFsuite: Goで書かれた高速なアクティブスキャナーで、CRLF injectionの脆弱性を体系的にテストします。

crlfuzz: Unicode改行ペイロードをサポートするワードリストベースのファーザーで、エッジケースやエンコーディングのバイパスを発見します。

crlfix: 2024年のツールで、GoプログラムによるHTTPリクエストを修正し、内部サービスのCRLF脆弱性をテストします。

AcunetixやInvictiなどの総合的なウェブアプリケーションセキュリティスキャナーには、これらの検出モジュールが含まれており、定期的なセキュリティ評価に役立ちます。

総合的な予防戦略

入力検証とサニタイズ

CRLF injectionに対する最も基本的な防御策は、すべてのユーザー入力を潜在的に危険とみなすことです。アプリケーションは、信頼できないデータをHTTPヘッダーやログに直接組み込む前に、厳格な検証を行う必要があります。

効果的な入力検証: - ホワイトリスト: 許容される文字のパターンを定義し、それ以外を拒否 - CRLFシーケンスの除去: \r, \nおよびそのエンコードバリアントをすべて除去 - 長さ制限: 過度に長い入力を防止 - 型の強制: 数値やメールアドレス、URLなど期待される型に制限

出力エンコーディング

CRLF文字の除去が難しい場合、出力エンコーディングを利用します。特殊文字をHTTP構造やログフォーマットに影響しない形に変換します。

HTTPヘッダーには、フレームワーク固有のエンコーディング関数を使用: - Java: StringEscapeUtils.escapeJava()やOWASP ESAPIのエンコーディング - PHP: htmlspecialchars()やfilter_var() - Python: URLエンコーディング関数やフレームワークのヘッダー検証 - .NET: HttpUtility.UrlEncode()やサニタイズメソッド

フレームワークレベルの保護

最新のウェブフレームワークは、CRLF injectionの保護機能を標準搭載しています。開発者は: - 最新のセキュリティパッチを適用 - 利用可能な場合は自動ヘッダー検証を有効化 - セキュリティ機能を無効化しない - ヘッダー操作にはフレームワークのメソッドを使用し、手動の文字列連結を避ける

多くのフレームワークは、ヘッダー値の自動検証とCRLFシーケンスの排除を行い、アプリケーションレベルの検証に頼らない防御層を提供します。

セキュアなログ記録

ログのインジェクションを防ぐには、特定の対策が必要です:

OWASP ESAPI Logger: CRLF文字を自動的に除去し、非英数字データをエンコードするロギングインターフェースを提供します。Log4jやJava標準のロギングと連携します。

JSONによる構造化ログ: ログをJSON形式に変換し、各エントリを個別のオブジェクトにすることで、インジェクションを防ぎます。ELKスタック（Elasticsearch, Logstash, Kibana）などのログ管理システムと併用します。

エンコード前のログ記録: ユーザーデータにエンコード関数を適用してからログに書き込みます:

logger.info("User login: " + ESAPI.encoder().encodeForHTML(username));

Logback設定: Spring Bootアプリでは、JSONエンコーダを設定して特殊文字を自動エスケープし、ログインジェクションを防止します。

セキュリティヘッダーと設定

防御層を追加: - Content Security Policy (CSP): CRLF injectionを完全に防ぐわけではありませんが、ヘッダーとHTML両方にポリシーを設定し冗長性を確保 - 不要なヘッダーの無効化: 必要のないHTTPヘッダーを削除 - HSTS: HTTPSを強制し、中間者攻撃を防止 - Cache-Control: キャッシュ動作を適切に設定し、キャッシュポイゾニングのリスクを軽減

コードレビューとセキュリティテスト

CRLF injectionの検出は、開発ライフサイクルに組み込むべきです: - ヘッダー操作やロギングコードの定期的なレビュー - 自動化されたセキュリティテストにCRLF injectionテストを含める - 脆弱性を狙ったペネトレーションテスト - セキュアコーディングの教育と脆弱性パターンの理解

フレームワーク別の考慮点

Javaアプリケーション

OWASP ESAPIを利用したエンコーディングと検証:

String sanitized = ESAPI.encoder().encodeForURL(userInput);

ロギングには、ESAPI Loggerを使いCRLFシーケンスを自動的に処理:

Logger logger = ESAPI.getLogger("SecurityLogger");
logger.info(Logger.SECURITY_SUCCESS, "User action: " + userAction);

NettyのDefaultHttpHeadersクラスは、コンストラクタのパラメータでヘッダー検証の有効化/無効化を制御します。常にnew DefaultHttpHeaders(true)を使用して検証を有効にします。

PHPアプリケーション

PHP開発者は、組み込みのフィルタリングと検証を利用:

$cleaned = filter_var($input, FILTER_SANITIZE_STRING);
$encoded = urlencode($input);

ヘッダーにはheader()関数を使い、適切な検証とレスポンス構築時の手動文字列連結を避けます。

Python/Djangoアプリ

Djangoは最新バージョンでヘッダー値の検証を自動的に行います。手動でヘッダーを操作する場合:

from django.utils.http import urlencode
from urllib.parse import quote

sanitized = quote(user_input, safe='')

ログ記録にはPythonの標準loggingモジュールを使い、特殊文字をエスケープするフォーマッタを適用します。

Node.js/Expressアプリ

Expressアプリは、入力の検証とサニタイズを行います:

const validator = require('validator');
const sanitized = validator.escape(userInput);

ヘッダーには、Expressのビルトインメソッドを使い、手動のヘッダー構築を避けます:

res.redirect(301, validator.escape(userUrl));

CRLF保護の未来

ウェブ技術の進化に伴い、CRLF injectionに対する防御も進化しています。HTTP/2やHTTP/3はバイナリフレーミングを導入し、プロトコルの構造からCRLFの依存を排除しつつあります。ただし、多くのアプリケーションはHTTP/1.1で動作しており、CRLF injectionの防御は依然として重要です。

JSONベースの通信を採用する最新のAPIフレームワークは、構造化されたフォーマットによりCRLF injectionに対して自然に耐性があります。ただし、従来のHTTPヘッダーやログシステムは依然として脆弱です。

セキュリティの自動化やAIによるコード解析ツールは、開発段階でCRLF injectionの脆弱性を検出し、セキュリティを早期に組み込む動きが進んでいます。これにより、展開前に脆弱なコードパターンを特定し、リスクを低減します。

結論

CRLF injectionは2025年においても重要なウェブアプリケーションのセキュリティ課題です。 newline文字をHTTPストリームに挿入するだけのシンプルな攻撃ですが、レスポンスの乗っ取りやログ改ざん、セッションの乗っ取り、セキュリティ制御の回避といった高度な攻撃に発展します。

組織は、厳格な入力検証、出力エンコーディング、フレームワークレベルの保護、セキュアなロギングを徹底し、開発者教育や自動化されたセキュリティテストと併用して、これらの攻撃から守る必要があります。技術の進化とともに、新しいプロトコルや通信方式はリスクを低減しますが、レガシーシステムや従来のHTTP通信は依然として脆弱性の対象です。常に警戒を怠らず、定期的な脆弱性テストと堅牢な開発慣行を維持しましょう。

---

キーワード: CRLF injection, HTTP response splitting, ログインジェクション, ウェブアプリケーションセキュリティ, ヘッダー操作, セキュリティ制御回避, 入力検証, 出力エンコーディング, XSS, Cookie injection, キャッシュ汚染, ウェブ脆弱性, サイバーセキュリティ 2025