メールヘッダインジェクションとは？仕組みと対策をわかりやすく解説
公開日：
※当サイトはアフィリエイトプログラムを利用しています。
「お問い合わせフォームを設置しただけなのに、サイトが迷惑メールの発信元にされていた」と聞くと、そんなことが起きるの？と感じるかもしれません。
お問い合わせフォームやメルマガ登録フォームといった、ほとんどのWebサイトにある身近な機能に潜む脆弱性がメールヘッダインジェクションです。
フォームの入力欄に不正な文字列を紛れ込ませることで、送信されるメールのヘッダ（宛先や差出人などの情報）を攻撃者に書き換えられてしまう、地味ながら被害の広がり方が大きい攻撃なんですね。
メールヘッダインジェクションの仕組みを分かりやすく解説し、サイト運営者が今日から実践できる予防策まで紹介していきます。
メールヘッダインジェクションってどんな攻撃？
メールヘッダインジェクションとは、お問い合わせフォームの入力欄（名前欄・件名欄・メールアドレス欄など）に不正な文字列を紛れ込ませることで、送信されるメールのヘッダ部分（From、To、Cc、Bccなど）を攻撃者が勝手に書き換えてしまう攻撃です。
本来であれば、利用者が入力できるのは「本文」や「件名」といった限られた範囲のはず。
ところがサーバー側の処理に不備があると、入力欄に特殊な制御文字を混ぜ込むことで、メールの構造そのものに手を加えられてしまいます。
ここで、専門用語を簡単に整理しておきましょう。
- メールヘッダとは
- From（差出人）、To（宛先）、Cc、Bcc、Subject（件名）など、メールの「宛先や内容の種類」を示す部分。本文とは改行によって区切られている。
- CRLFインジェクションとは
- メールヘッダの区切りに使われる改行コード（CR・LF）を入力欄に混入させ、行を勝手に追加してしまう手口。メールヘッダインジェクションの多くはこの仕組みを悪用している。
- メールヘッダインジェクションの主な悪用パターン
- 「宛先を勝手に追加するBcc追加型」「差出人を偽装するFrom偽装型」「本文を差し替える本文改ざん型」の3つに大きく分けられます。
例えば「お名前」欄に、以下のような文字列を入力して送信したとします。
田中太郎
Bcc: victim1@example.com, victim2@example.com...
このような形で送信すると、サーバー側が意図せずBccヘッダを追加してしまう、という具合です。
攻撃者からすれば「送信先を勝手に増やせる」「差出人を偽装できる」「本文を差し替えられる」といった操作が可能になります。
日本語圏では、かつてPHPのmb_send_mail()関数において、件名などに含まれる改行コードのチェックが不十分だったことが原因で、多くのサイトがこの脆弱性を抱えていた時期がありました。
現在は多くのフレームワークやライブラリで対策が組み込まれていますが、独自実装のフォームや古いシステムでは、今なお同様の問題が残っていることがあります。
被害に遭うとどうなる？
この脆弱性を突かれると、サイトのメール送信機能そのものが攻撃者に乗っ取られたのと同じ状態になるため、サイト運営者・利用者の双方に被害が及びます。
迷惑メールの踏み台にされる
もっとも典型的な悪用が、正規サイトのメール送信機能を踏み台にして大量の迷惑メールをばらまく手口です。
攻撃者はBccヘッダに何百、何千という宛先を追加し、そのサイトのサーバーを経由してスパムを一斉送信します。
- 送信元として記録される
送信元として記録されるのはサイト運営者のサーバー。踏み台にされた自覚がないまま、加害者側に立たされてしまう - ブラックリスト登録
結果として、そのドメインやサーバーのIPアドレスが迷惑メール業者のブラックリストに登録される - 正規メールが届かなくなる
会員登録確認や注文確認など、正規のメールまで相手に届かなくなる二次被害が発生する
送信元を偽装したなりすまし
Fromヘッダを書き換えられることで、実在する企業や個人になりすましたメールを送ることも可能になります。
受信者からすれば「見覚えのあるサイトから届いたメール」に見えてしまうため、警戒心が緩みやすくなるのがポイントです。
フィッシングへの悪用
正規サイトの問い合わせフォーム経由で送信されたメールは、SPFやDKIMといった送信ドメイン認証を通過しやすいという特徴があります。
攻撃者はこの性質を利用し、フィッシングリンクを埋め込んだ本文を、あたかも正規サイトからの通知のように送りつけるのです。
個人情報の漏えい・二次被害
フォームの管理者宛メールをBccやCcの追加によって外部に横流しされると、フォームに入力された個人情報（氏名・連絡先・相談内容など）が第三者に流出する危険も。
相談内容がセンシティブな場合、被害はさらに深刻になります。
個人事業主やサイト運営者向けの緊急対応
レンタルサーバーを利用したり、独自にお問い合わせフォームを運用している個人事業主やサイト運営者の方が、万が一「大量の不審な送信ログがある」「サーバー会社から迷惑メールに関する警告が届いた」と気づいた際、すぐに実行できる緊急対応です。
- 被害の拡大を止める
- ・フォームを一時的に停止する
お問い合わせフォームやメルマガ登録フォームを、原因が判明するまで一時的に非公開にする。 - ・メール送信機能を制限する
サーバーの管理画面から、メール送信数の上限設定や送信機能そのものの一時停止ができないか確認する。
- 証拠保全と原因特定
- ・メール送信ログをダウンロードする
レンタルサーバーの管理機能から、直近の送信ログをすべて手元に保存する。 - ・フォームの入力履歴を確認する
どの入力欄に、どんな不審な文字列（改行コードなど）が混入していたのかを特定し、被害範囲を把握する。
- 安全な状態への復旧と根本対策
- ・制御文字のチェック処理を追加する
フォームのコードに、改行コードなどの制御文字を検証・除去する処理を組み込む。 - ・信頼できるメール送信ライブラリに切り替える
自前実装をやめ、PHPMailerなど実績のあるライブラリやメール配信APIに置き換える。 - ・古いプラグイン・スクリプトの更新または削除
脆弱性が指摘されている古いフォームプラグインや、身に覚えのないスクリプトが設置されていないか点検する。
- 外部への報告とユーザー対応
- ・レンタルサーバー会社への連絡
被害の状況をサポート窓口に報告する。ドメインやIPアドレスがブラックリストに登録されている場合、解除申請が必要になることもある。 - ・フォーム利用者へのアナウンス
個人情報が外部に漏れた可能性がある場合は、サイト上やメールで速やかに公表し注意喚起する。 - ・公的窓口への相談
必要に応じて、警察のサイバー犯罪相談窓口や、IPA（情報処理推進機構）へ相談・報告する。
※個人サイトであっても、迷惑メールの踏み台にされてしまうと、社会的信用を大きく失うリスクがあります。
自力での原因特定やコード修正が難しい場合は、無理をせずサイトの制作会社やセキュリティの専門家に調査を依頼することをおすすめします。
利用しているサービスが被害に遭った場合の対処法
クロスサイトスクリプティングとは異なり、メールヘッダインジェクション自体はログインセッションを奪う攻撃ではありません。
そのため、利用者側に起きることは主に次の2パターンです。
クロスサイトスクリプティング（XSS）とは？仕組み・被害事例・対策をわかりやすく解説
- そのサービスを名乗るメールが届いた場合
- ・送信元アドレスの表示だけで信用しない
正規ドメインに見えても、踏み台にされたサイトから送られている可能性があります。 - ・本文中のリンクは踏まず、公式サイトへ直接アクセスして確認する
ブックマークや検索から公式サイトにアクセスし、お知らせやログイン履歴を自分で確認するのが確実です。
- 問い合わせ内容の漏えいが公式発表された場合
- ・漏えいした情報の範囲を確認する
氏名・連絡先程度か、相談内容などセンシティブな情報まで含まれるかで、警戒すべき度合いが変わります。 - ・便乗フィッシングに注意する
「情報漏えいのお詫びとご案内」などを装い、個人情報の再入力を求める二次フィッシングが送られてくることがあります。案内メールのリンクは踏まず、公式サイトから確認しましょう。
あわせて読みたい
フィッシング被害に遇ったら？フィッシングを防ぐ確実な方法とは
システム開発（設計）側の根本対策
独自にお問い合わせフォームを開発したり、既存システムをカスタマイズしたりする際は、次の3つの防衛線を組み合わせることで、メールヘッダインジェクションのリスクを大幅に減らせます。
1️⃣制御文字の除去・検証を徹底する
もっとも基本的な対策は、フォームから受け取った入力値に改行コード（CR・LF）やヌルバイトなどの制御文字が含まれていないかを必ずチェックし、含まれていれば送信を拒否するか、無害化して除去することです。
特に件名・送信者名・メールアドレスといった「ヘッダに直接使われる値」は、厳密なバリデーションが欠かせません。
2️⃣信頼できるメール送信ライブラリ・APIを使う
自前でヘッダを組み立てる実装は、思わぬ抜け漏れが起こりやすいものです。
PHPMailerなど実績のあるライブラリや、SendGridをはじめとするメール配信APIを利用すると、ヘッダインジェクション対策があらかじめ組み込まれていることが多く、リスクを大きく下げられます。
3️⃣定期的な脆弱性診断とログの確認
古いCMSやプラグイン、自作フォームをそのまま使い続けているサイトでは、既知の脆弱性が放置されているケースが少なくありません。
定期的な脆弱性診断に加え、メール送信ログを確認し、通常ではあり得ない宛先数や送信頻度がないかをチェックする運用も有効です。
あなたが運営するサイトを守るための基本対策
根本対策がしっかり施された安全なシステムを土台とし、その上で運営者自身もセキュリティ対策を重ねることが大切。
「小規模なサイトだから狙われない」という考えは危険です。
ボットによる自動巡回で脆弱なフォームを探し出し、無差別に踏み台として悪用するケースが珍しくありません。
- ・お問い合わせフォームのプラグインやスクリプトを常に最新の状態に保つ
- ・使用していない古いフォームやスクリプトは削除する
- ・レンタルサーバーが提供するWAFを有効にする
- ・独自開発したフォームは、開発会社やエンジニアにセキュリティ対策を確認してもらう
クロスサイトスクリプティングと同じく、メールヘッダインジェクションも「どうすれば防げるか」という答えが確立されている手口です。
せっかく育ててきた大切なサイトが、ある日突然迷惑メールの発信基地にされてしまわないよう、ぜひ今日のうちにご自身のサイトのフォームを一度チェックしてみてくださいね。
メールヘッダインジェクションのよくある質問
メールヘッダインジェクションについて、特に多い疑問をQ&A形式でまとめました。記事の内容とあわせて確認してみてください。
- 目次
- ・まともなレンタルサーバーを借りていれば起きませんか？
- ・バイブコーディングで作ったアプリでも起こりますか？
- ・利用者側では何に気をつければいいですか？
- ・WordPressのお問い合わせフォームでも起こりますか？
- ・正規ドメインから届いたメールなら安全ですか？
Q. まともなレンタルサーバーを借りていれば起きませんか？
A.「サーバーの質が良ければ安心」とは言い切れません。原因の多くは、サーバー自体ではなく、その上で動いているお問い合わせフォームのプログラム側の実装にあるからです。
どれだけ高性能で信頼できるレンタルサーバーを借りていても、フォームのコードが入力値のチェックをしていなければ、脆弱性はそのまま残ります。
とはいえ、サーバーの質が無関係というわけでもありません。
- ・WAFが標準で有効になっている、または簡単にオンにできる
- ・PHPなどの実行環境が自動で最新版に更新される
- ・異常なメール送信量を検知して自動的に止めてくれる仕組みがある
- ・サポートが充実していて、悪用に気づいた時の対応が早い
イメージとしては、サーバーは「頑丈な建物」、フォームのプログラムは「その建物の中にある鍵付きの部屋」のようなものです。
建物自体がどれだけしっかりしていても、部屋の鍵（＝コードのバリデーション）が壊れていれば、そこから入られてしまいます。
「PHPMailerなど実績のあるライブラリを使う」「入力値の制御文字をチェックする」といった対策は、サーバーのグレードに関係なく、フォームを設置している人自身が確認すべきポイントです。
Q. バイブコーディングで作ったアプリでも起こりますか？
A.むしろリスクが上がりやすいと言えます。
バイブコーディングは「動くものを早く作る」ことが優先されるため、入力値のチェックやエスケープ処理といった、画面上では見えない地味な処理が省略されやすい傾向があるからです。
AIに「お問い合わせフォームを作って」とだけ頼むと、見た目やフォーム送信の動作は完成しても、CRLFインジェクション対策までは自動的に含まれるとは限りません。
先ほどの「サーバーは頑丈な建物、フォームは鍵付きの部屋」の例えで言うと、バイブコーディングは部屋の鍵がちゃんと閉まっているか、住人（＝開発者）自身が確認していない状態になりやすいということ。
生成されたコードをそのままデプロイしてしまうと、脆弱性があっても気づく機会がありません。
「入力値に改行コードが含まれていないかチェックして」「PHPMailerを使って安全にメール送信を実装して」のように、AIに具体的な指示を出せば、脆弱性を作り込まずに実装させることも十分可能。
問題は技術そのものではなく、セキュリティ観点でのレビューをする文化があるかどうかに尽きます。
あわせて読みたい
バイブコーディングとは？AI時代のアプリ開発に潜むリスクと正しい向き合い方
Q. 利用者側では何に気をつければいいですか？
A.フォームの実装自体は利用者が直接操作できる部分ではありませんが、この仕組みを知っておくことには意味があります。
「実在する企業のドメインから届いたメールだから安全」とは限らない、という事実です。
本文中のリンク先URLを安易にクリックしない、少しでも違和感のある文面には警戒するという基本姿勢は、こうした手口に対しても有効な防御になります。
Q. WordPressのお問い合わせフォームでも起こりますか？
A.実績のあるプラグイン（Contact Form 7など）を最新の状態で使っている限り、基本的な対策は組み込まれています。
ただし、古いバージョンのまま放置していたり、独自にカスタマイズを加えていたりする場合は、リスクが残ることがあります。
プラグイン・本体ともに常に最新の状態を保つことが基本です。
Q. 正規ドメインから届いたメールなら安全ですか？
A.必ずしもそうとは言い切れません。
メールヘッダインジェクションが成立しているサイトを踏み台にされると、送信元アドレスが正規のものに見えても、実際には第三者が仕込んだ内容が届いている可能性があります。
送信元表示だけで判断せず、本文の内容やリンク先を冷静に確認する習慣が大切です。