メールヘッダーインジェクションとは？仕組み・被害例・対策をわかりやすく解説

フォームからのお問い合わせメールが届いた裏で、自社サーバーが何千件ものスパムを外部へ配信していたとしたら——こう聞いてもピンとこない方も多いかもしれません。しかし、メールヘッダーインジェクションは国内のWebサイトでも長年確認され続けている、地味ながら危険な脆弱性です。

特にPHPで構築されたお問い合わせフォームや会員登録フォームを持つサイトは要注意です。放置すると自社ドメインがスパムの踏み台になり、正規のメールも届かなくなる深刻な事態を招くことがあります。

この記事では、メールヘッダーインジェクションの仕組み・実際の被害事例・開発者と情シスがすぐに実践できる対策を解説します。

メールヘッダーインジェクションとは？

メールヘッダーインジェクションとは、WebアプリケーションのメールフォームやPHPなどのスクリプトが、ユーザーの入力値をそのままメールヘッダーに組み込んでしまうことで発生する脆弱性です。

インターネットの標準メールプロトコル（SMTP）では、各ヘッダーはCRLF（キャリッジリターン「\r」＋ラインフィード「\n」、いわゆる改行文字）で区切られています。攻撃者がこのCRLF文字を入力値に混入させると、任意のヘッダーフィールドを追加・改ざんできてしまいます。

攻撃の仕組み（敵を知る）

典型的な攻撃シナリオを見てみましょう。お問い合わせフォームの「お名前」フィールドに、次のような文字列が送信されたとします。

# 攻撃者が「お名前」フィールドに入力した文字列（CRLFを埋め込んでいる）
山田太郎\r\nBcc: spam1@attack.example,spam2@attack.example,...,spam1000@attack.example

サーバー側がこの入力値をそのままメールヘッダーの「From:」フィールドに組み込むと、生成されるメールのヘッダーは次のようになります。

From: 山田太郎
Bcc: spam1@attack.example,spam2@attack.example,...,spam1000@attack.example
Subject: お問い合わせ

こうして自社のメールサーバーが、無関係な宛先へスパムを大量送信する踏み台になってしまいます。

攻撃が成立しやすい条件

・PHPのmail()関数を直接使用: 古くからある実装で最も被害報告が多い
・入力値をヘッダーに無検証で代入: 名前・件名・メールアドレスをそのまま結合している
・マルチバイト文字を使った改行の埋め込み: URLエンコード（%0d%0a）でも同様の攻撃が成立する
・古いフレームワーク: メール送信ライブラリが改行チェックを行わない旧バージョン

実際の被害事例

国内でも、中小企業のお問い合わせフォームやECサイトの会員登録フォームを通じて、自社ドメインからスパムが大量送信されるケースが継続的に報告されています。被害が発生すると次のような連鎖が起こります。

・送信元IPがブラックリスト登録: 正規のメールも届かなくなる
・ドメインの信頼性低下: 受信側サーバーにスパム認定され拒否される
・ホスティング会社からの送信停止: メールアカウントやサービスが停止されることも
・取引先への誤送信: フィッシングメールに自社ドメインが悪用され信頼を損なう

スパム送信自体は攻撃者が目的を達しますが、被害を受け続けるのは踏み台にされた自社サイトの運営者です。

具体的な防御手順

1. 入力値から改行文字を検出・除去する

最も基本的な対策は、ユーザー入力からCRLF（\r\n）を除去または拒否することです。

# PHPでの改行文字の除去例
$name    = str_replace(["\r", "\n"], '', $_POST['name']);
$subject = str_replace(["\r", "\n"], '', $_POST['subject']);
$from    = str_replace(["\r", "\n"], '', $_POST['email']);

# 送信元メールアドレスの書式検証も必須
if (!filter_var($from, FILTER_VALIDATE_EMAIL)) {
    die('不正なメールアドレスです。');
}

2. メール送信ライブラリを使用する

PHPのmail()関数を直接使う実装は、ヘッダーインジェクションへの対策が不十分になりがちです。セキュリティが考慮された専用ライブラリを使うことでリスクを大幅に下げられます。

・PHPMailer: 国内外で広く使われる定番ライブラリ。ヘッダー操作への保護機能あり
・Symfony Mailer: Symfonyエコシステムで採用されるメール送信コンポーネント
・各フレームワーク標準機能: Laravel Mail、CakePHP EmailなどはCRLF対策が実装済み

ライブラリを使う際も、常に最新バージョンへ更新し続けることが前提です。

3. ホワイトリスト方式で入力値を制限する

「名前」フィールドに使える文字種をあらかじめ定義し、それ以外を拒否するホワイトリスト方式が理想的です。

# 名前フィールドに日本語・英字・スペースのみを許可する例
if (!preg_match('/^[\p{L}\p{N} \u3000\u30FC\u3001\u3002\u30FB]+$/u', $name)) {
    die('使用できない文字が含まれています。');
}

「どんな文字でも通す」設計より「必要な文字だけ通す」設計のほうが、脆弱性の根本的な封鎖につながります。

4. メールサーバーの送信ログを定期確認する

万が一の踏み台化に早期に気づくため、送信ログを定期確認する習慣をつけましょう。Postfixを使っているLinuxサーバーなら次のコマンドが有効です。

# Postfixの送信ログを確認（直近100件）
sudo tail -100 /var/log/mail.log | grep "status=sent"

# 日別の送信件数が急増していないか確認
sudo grep "status=sent" /var/log/mail.log \
  | awk '{print $1, $2}' | uniq -c | sort -rn | head -10

Linuxサーバーのログ監視全般については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。

中小企業でも今日からできること

開発担当者がいない環境でも、次の点を確認・依頼することで対策を進められます。

・フォームの送信テスト: 名前や件名フィールドに「%0d%0a」や改行文字を入力し、エラーが出るか確認する
・制作会社への確認: サイト制作時・リニューアル時に「メールヘッダーインジェクション対策の有無」を確認項目に追加する
・ライブラリのバージョン確認: 使用しているメール送信ライブラリが最新版かを確認し、古ければ更新を依頼する
・SPF・DKIM・DMARCの設定: 自ドメインからの不正メール送信を受信側で弾く仕組みを整備する
・定期的な脆弱性診断: メールフォームを診断スコープに必ず含めるよう診断会社に明示する

なお、メールの誤送信防止と合わせて整備すると、メールセキュリティ全体の底上げにつながります。詳しくは中小企業のメール誤送信対策もあわせてご覧ください。

よくある誤解と注意点

【誤解1】「HTMLメールを使っているから安全」

メールヘッダーインジェクションはメール本文の形式（HTMLかテキストか）に関係なく、ヘッダー部分の処理が問題です。HTMLメールを使っていても、ヘッダー操作への対策がなければ脆弱なままです。

【誤解2】「SSL/TLSでメールを送信しているから安全」

SSL/TLSは通信経路上の盗聴を防ぐ技術です。ヘッダーインジェクションはサーバー内部でのメール生成時に発生するため、SSL/TLSとは別の問題として対処が必要です。

【誤解3】「XSS対策をしているから問題ない」

XSSはブラウザ上でのスクリプト実行を防ぐ対策です。メールヘッダーインジェクションはWebページへの出力とは別の処理で発生するため、XSS対策とは独立した実装が必要です。

セキュアコーディングの基本原則についてはセキュアコーディング実装ガイドもあわせてご確認ください。

本記事のまとめ

メールヘッダーインジェクションは、古くから知られていながら現場で後回しにされがちな脆弱性のひとつです。特に「お問い合わせフォーム」「会員登録フォーム」「見積り依頼フォーム」を持つサイトは、今すぐ対策状況を確認することをお勧めします。正しく知って正しく備えることが、自社の信頼を守ることに直結します。