境界線上の脆弱性：HTTPのCRLFがネットワークの深淵で語ること
ネットワークの現場に身を置いていると、「HTTPはテキストベースのプロトコルである」という事実にしばしば救われ、そして同時に裏切られる。
特にHTTP/1.1までを支配してきた`CRLF（\r\n: 0x0d 0x0a）`という区切り文字は、実装の簡便さを提供する一方で、実装者と攻撃者の双方に「境界」を操作する余地を与えてしまった。今日は、この一見無害な2バイトの制御コードが、いかにして現代のハイパフォーマンスなインフラに暗い影を落とし、そして我々エンジニアがどうこれと対峙すべきかについて、パケットの深層から紐解いていきたい。
—
1. CRLFという「境界」の物理学
TCPのストリームにおいて、HTTPリクエストとレスポンスは「終わりなきバイトの奔流」に過ぎない。その中で、パーサーが「どこでヘッダーが終わり、どこからボディが始まるのか」を判断するための羅針盤こそがCRLFである。
GET /index.html HTTP/1.1\r\n
Host: example.com\r\n
\r\n
この最後の空行、つまり二連続のCRLFが、パーサーに対する決定的な「停止命令」だ。しかし、HTTP/1.1の仕様（RFC 7230/9112）がこの厳格な区切りを求める一方で、アプリケーション層の脆弱性がここに介入する。いわゆる「HTTPレスポンス分割攻撃（CRLF Injection）」だ。ユーザー入力がヘッダー値としてそのまま反映される際、攻撃者が意図的に`%0d%0a`を注入することで、パーサーを欺き、本来のレスポンスの直後に「偽のHTTPレスポンス」を捏造する。
これは単なる文字列操作の不備ではない。TCPストリームを共有するコネクションにおいて、クライアント側が本来受信するはずのないレスポンスを後続の「リクエストへの回答」と誤認させる、プロトコル層の解釈の齟齬を突いた攻撃だ。
—
2. パフォーマンスとセキュリティの狭間で：バッファチューニングの要諦
インフラアーキテクトとして頭を悩ませるのは、この解析コストとパフォーマンスのトレードオフだ。
HTTP/1.1では、TCPセグメントのバッファリングとCRLFの検索コストが直接的にRTT（Round Trip Time）に影響する。特にTLSハンドシェイクが完了した後、最初のTCPセグメントでどれだけのヘッダーを詰め込めるか（IW: Initial Windowの最大活用）は、TTFB（Time to First Byte）を左右する。
もしバックエンドのサーバーがCRLFを検索するために不適切なバッファ管理を行っていれば、TCPのセグメント分割のタイミングによっては、パーサーがヘッダーの断片を待機し、数ミリ秒のレイテンシロスが生じる。
カーネルレベルでの最適化（Linux）
カーネルパラメータでTCPスタックをチューニングし、ヘッダー処理のオーバーヘッドを抑える際、以下の設定を検討してほしい。
TCPの送信バッファを動的に調整し、低遅延でのヘッダー送信を促進
sysctl -w net.ipv4.tcp_rmem=”4096 87380 16777216″
sysctl -w net.ipv4.tcp_wmem=”4096 65536 16777216″
TCP_NODELAY (Nagleアルゴリズム無効化) をアプリケーション側で徹底する
小さなHTTPヘッダーパケットを即座にネットワークへ放出させる
—
3. 次世代への教訓：HTTP/2とHTTP/3が解決したこと
正直に言おう。CRLFの脆弱性と、それに付随する「ヘッダーのパースコスト」を根本的に解決したのは、HTTP/2以降のバイナリフレーム化だ。
HTTP/2において、ヘッダーは`HPACK`というアルゴリズムで圧縮され、CRLFという「文字列の区切り」から解放された。長さ（Length）が明示されたフレーム構造を採用することで、パーサーは「どこまでがヘッダーか」を推測する必要がなくなった。これにより、CRLF Injectionという脆弱性はプロトコルレベルで無効化されたと言っても過言ではない。
しかし、レガシーなHTTP/1.1プロキシやロードバランサーが手前に存在する限り、我々は依然としてCRLFの亡霊と戦い続けなければならない。
—
4. 現場でのトラブルシューティングと回避策
もしあなたが今、WAFをすり抜けるCRLF攻撃を懸念しているならば、以下の防衛戦略を即座に適用することを推奨する。
1. 入力の正規化（Canonicalization）: ユーザー入力をヘッダーに含める際は、`\r`や`\n`を許容しないバリデーターを必ず通すこと。
2. Webサーバーのプロトコル解釈の厳格化: nginxを使用している場合、`merge_slashes`や`ignore_invalid_headers`の挙動を精査し、意図しないリクエストラインの解釈を封じる。
3. HTTP/2への完全移行: 可能な限り、クライアントからバックエンドまでをHTTP/2またはHTTP/3で統一し、HTTP/1.1のレガシーなパース処理を排除する。
nginx設定例：不正なヘッダー文字を拒否し、CRLF注入を未然に防ぐ
http {
# 不正な文字を含むリクエストを拒否する設定
ignore_invalid_headers on;
# リクエストのヘッダーサイズを制限し、メモリ枯渇攻撃を防ぐ
large_client_header_buffers 4 8k;
}
結びに代えて
CRLFという小さな文字コードに焦点を当てることは、単なるセキュリティ対策ではない。それは、ネットワーク通信がいかにして抽象化され、そして現実のハードウェア（CPUのパイプラインやNICのバッファ）と衝突しているかを理解する試みだ。
技術は進歩する。だが、プロトコルの基礎にある「境界をどう定義するか」という問いは、これからも形を変えて我々に突きつけられるだろう。パケットの深淵を覗き込むとき、そこにあるのはただのデータではなく、設計者の意志と攻撃者の知恵のぶつかり合いなのだ。
さあ、次はどのプロトコルの脆弱性を分解しようか。ネットワークの旅に終わりはない。
コメント