CRLF インジェクション.

CRLF インジェクションは、多くのテキストベース・プロトコルで行末を示す CR(0x0D)と LF(0x0A)バイト列の特殊な意味を悪用します。アプリケーションが検証されていないユーザ入力を HTTP レスポンスヘッダ、ログ、SMTP コマンド、LDAP クエリへ反映する場合、攻撃者は CRLF と追加コンテンツを挿入してヘッダを偽造する、レスポンスを分割する、ログを隠す、コマンドを密輸するといった攻撃が可能となります。この弱点は CWE-93(CRLF シーケンスの不適切な無害化)として分類され、HTTP ヘッダに特化した下位分類が CWE-113(HTTP リクエスト/レスポンス分割)です。

Web では HTTP レスポンス分割が最も危険で、Sanctum 社の Amit Klein が 2004 年の論文で初めて記述しました。注入された CRLF がヘッダブロックを終了させるため、攻撃者は完全に自分が制御する 2 つ目のレスポンスを追加でき、共有キャッシュの汚染、任意 Cookie の設定、ブラウザが信頼する本文への XSS 注入につながります。この不具合は標準ライブラリでも繰り返し現れます。CVE-2019-9740 では、Python の urllib.request.urlopen に渡す URL 中の CRLF 列が HTTP ヘッダを注入でき(クエリ文字列経由で Redis コマンドまで)、Python 2.7.17 および 3.5.10/3.6.10/3.7.4 で修正されました。対策には、ヘッダに渡るすべての入力での CR/LF 拒否またはパーセントエンコード、ヘッダ値中の制御文字を拒否する上位 API、生の文字列連結ではなく厳格で構造化されたログエンコーダの利用があります。

flowchart TD
  A[ユーザ入力<br/>name=foo%0d%0aSet-Cookie: admin=true] --> B{CR LF を検証 / 除去?}
  B -->|いいえ| C[入力をそのままヘッダへ書き込み]
  C --> D[CRLF が現在のヘッダを終了]
  D --> E[攻撃者が制御するヘッダまたは本文]
  E --> F[キャッシュ汚染 / Cookie 注入 / XSS]
  B -->|はい、CR LF を拒否| G[安全なレスポンス]