メールヘッダーインジェクション：その「改行」がシステムをゾンビ化させる
現場でインシデント対応をしていると、「まさかメール送信機能が攻撃の踏み台にされるとは」と青ざめる開発者に何度も出会う。メールヘッダーインジェクションは、Webアプリケーションの脆弱性の中でも極めて古典的だが、未だに防衛が甘い箇所だ。
攻撃者は、メール送信機能という「信頼されたサーバーからの発信」を悪用し、あなたのシステムをスパム送信の踏み台（オープンリレー）に変えてしまう。今回は、この古くて新しい脅威のメカニズムと、二度と脆弱性を生み出さないための「鉄壁の防御」について解説しよう。
—
1. 攻撃のメカニズム：改行が作り出す「虚偽のヘッダー」
メールのヘッダー（To:, Subject:, From:など）は、本来プロトコルレベルで各行が \r\n (CRLF) で区切られている。攻撃者は、ユーザー入力値にこの改行コードを忍び込ませることで、メールサーバーを誤認させる。
例えば、Subject に Hello\r\nBcc: victim@example.com を送り込むと、受信側のメールサーバーは以下のように解釈してしまう。
Subject: Hello
Bcc: victim@example.com
(本来のメール本文…)
結果として、あなたのサーバーは知らないうちに第三者へメールをバラ撒く「スパムボット」に早変わりし、IPアドレスのブラックリスト入り（レピュテーション低下）という、ビジネスにとって致命的な損害を被ることになる。
—
2. なぜ修正パッチだけでは不十分なのか？
多くのエンジニアは「str_replaceで改行コードを消せばいい」と考えがちだ。しかし、攻撃者はエンコード手法を複雑化させたり、ライブラリのバグを突いたりしてくる。
鉄則は、「ユーザー入力をヘッダーの構築に直接使用しない」こと。 可能であれば、メール送信ライブラリが提供する「正規化されたメソッド」以外は使わないのが、セキュリティチーフとしての私の流儀だ。
—
3. 実装サンプル：こう書けば攻撃は成立しない
ここでは、PHPとPythonを用いた「攻撃を受け付けない」実装例を紹介する。
PHP: mb_send_mail を使う場合の鉄則
PHPの mail() 関数を直接叩くのは避け、必ず mb_send_mail を使う。しかし、ヘッダーにユーザー入力を入れる場合は、改行コードの有無を事前に厳格にチェックする必要がある。
/
function safe_send_mail($to, $subject, $message, $from) {
// 1. 改行コードが含まれていないか厳密にチェック（これが防波堤）
$headers = “From: ” . $from . “\r\n”;
if (preg_match(‘/(\r|\n)/’, $to) || preg_match(‘/(\r|\n)/’, $subject)) {
// ログを残して異常終了させる
error_log(“メールヘッダーインジェクションの試行を検知しました: ” . $subject);
return false;
}
// mb_send_mailは内部でヘッダーの折り返しなどを処理してくれるため推奨
return mb_send_mail($to, $subject, $message, $headers);
}
Python: email.message モジュールでの堅牢な構築
Pythonであれば、文字列を連結してヘッダーを作るのではなく、EmailMessage オブジェクトを使って構造化するのが正解だ。これにより、ヘッダーの構築がライブラリ側で管理される。
from email.message import EmailMessage
import smtplib
def send_secure_email(target_email, subject_text, body_text):
msg = EmailMessage()
msg.set_content(body_text)
# メッセージオブジェクトがヘッダーの妥当性を検証してくれる
msg[‘Subject’] = subject_text
msg[‘To’] = target_email
msg[‘From’] = “system@example.com”
# ユーザー入力を直接ヘッダー文字列に連結しないのが鍵
with smtplib.SMTP(‘localhost’) as s:
s.send_message(msg)
—
4. インフラ側で追い詰める：WAFと設定の重要性
アプリケーション層での防御が基本だが、防御は多層であるべきだ。
- WAFの活用: AWS WAFやCloudflareなどのルールで、
CRLFを含むリクエストを拒否するルールを有効化しておくこと。これは、アプリケーションのバグを修正するまでの「緊急避難」として非常に有効だ。 - メールサーバーの制限: 送信元IPの制限や、SPF/DKIM/DMARCの設定を厳格に行うこと。これらは、万が一アプリケーションが踏み台にされた際の「被害の拡散」を食い止める最後の砦となる。
—
最後に：エンジニアが持つべき「疑いの精神」
メール機能一つとっても、攻撃者は常に「想定外の入力」を投げ込もうと虎視眈々と狙っている。
「ユーザーが入力する値は、常に有害なコードになり得る」という前提に立ち、文字列操作が必要な箇所では、必ず「ホワイトリスト方式のバリデーション」を徹底してほしい。もし「この入力は本当にヘッダーに含まれる必要があるのか？」と少しでも迷ったら、設計を見直す勇気を持ってほしい。
技術は進歩するが、脆弱性の本質は変わらない。君たちが書くその一行が、明日誰かのインシデントを防ぐかもしれない。そう意識するだけで、コードの品質は劇的に向上するはずだ。頑張ってくれ。
コメント