問い合わせフォームが迷惑メールの踏み台にされる仕組み
自社サイトのお問い合わせフォームに、意味の通らない文面の送信が一日に何十件も届くようになった。あるいは、送った覚えのない自動返信メールについて外部から苦情が来た。サーバー会社からメール送信量に関する連絡が届いた。フォーム自体は普通に動いているので何が起きているのか分からない——という状況で読まれることを想定した記事です。
先に結論
- 迷惑メールの踏み台にされる経路の多くは、フォームの自動返信機能です。攻撃者は問い合わせ内容ではなく、自動返信の宛先と本文を狙っています
- 被害はサイト側ではなく第三者に出ます。自社サイトは無事に見えたまま、送信元として評価を落としていきます
- 確認は三つで足ります。自動返信の有無、送信ログの宛先の偏り、フォーム項目が本文に差し込まれているかを見ます
- 対策は入力制限より先に、返信の設計を見直すことです。reCAPTCHA を入れれば終わりという問題ではありません
何が起きているのか — 「送信者」が入れ替わる
お問い合わせフォームは、外部の人が入力した内容を、サーバーからメールとして送り出す仕組みです。言い換えると、サイトは小さなメール送信装置を一つ持っていることになります。ふだんは自社の担当者宛に届くだけなので、装置だという意識は持ちにくいところです。
攻撃者はこの装置に、自分では送りたくないメールを代わりに送らせます。自分のサーバーを用意せずに済み、しかも送信元は正規のサイトのドメインになります。受け取った側から見れば、見覚えのある企業や学校のドメインから届いたメールです。だから迷惑メールフィルタを通り抜けやすくなります。
厄介なのは、この間サイト自体は何も壊れないことです。ファイルも書き換わらず、データベースにも痕跡が残らず、表示も普段どおりです。改ざんのように「見れば分かる」異常が出ないため、管理者が自力で気づく機会がほとんどありません。
自動返信が狙われる理由
宛先も本文も外部から決まる
自動返信は、送信者が入力したメールアドレス宛に、サイト側から自動でお礼のメールを返す機能です。便利な機能ですが、構造として一つ特徴があります。宛先を外部の人が自由に決められるという点です。
さらに多くの設定では、入力された名前や問い合わせ本文を、自動返信メールの中に「お問い合わせ内容の確認」として差し込んでいます。つまり本文も外部の人が書けます。宛先が自由、本文が自由、送信元は正規ドメイン。この三つが揃った時点で、そのフォームは事実上「誰にでも何でも送れる送信フォーム」として使えてしまいます。
あわせて、宛先欄に改行と追加のヘッダー情報を混ぜ込み、一通の送信で複数人へ配る手口も古くから知られています。自作のフォームや、更新が止まったまま使われているプラグインで成立しやすい類のものです。更新できない状態のまま放置されたプラグインがある場合は、その理由から確認することになります。
管理者通知だけ見ていると気づけない
悪用されているとき、管理者宛に届く通知メールの本文には、日本語として意味のない文字列と、URL や請求を装った文言が並びます。担当者から見ると「変な迷惑メールが増えたな」で終わってしまう見え方です。
しかし本当の送信先は、自動返信の宛先の側にあります。管理者通知は、攻撃者にとっては副産物にすぎません。管理者宛の一通を見て判断するのではなく、同じ送信でもう一通どこへ出ているのかを見る必要があります。
被害はサイトではなく「ドメインの信用」に出る
この事故が他の障害と決定的に違うのは、サイトの表示が最後まで正常なままだという点です。影響は、メールの届きやすさに現れます。
- フォーム経由の送信量が急に増える
- 受信側のサービスでスパムと判定されはじめる
- 送信元のドメインや IP がブロックリストに登録される
- 自社の通常業務のメールが、相手に届かなくなる
学校法人なら保護者への一斉連絡、医療機関なら予約確認、企業なら見積書や請求書の送付。踏み台にされて本当に困るのは、問い合わせ対応ではなく日常の連絡のほうです。フォームを止めれば済む話に見えて、止めても届かない状態は残ります。
発覚の順番としては、サーバー会社から送信量超過の連絡が届いて初めて気づく、という形になりやすいものです。そして一度失った送信評価は、原因を止めてもすぐには戻りません。復旧に時間のかかる種類の事故だと考えておくのが妥当です。
自社のフォームを三つの角度から確認する
確認 1: 自動返信の設計
まず、自動返信を使っているかどうかを確認します。使っている場合は、返信メールの本文に入力内容をそのまま差し込んでいるかを見ます。差し込んでいるなら、差し込む項目を減らせないかを検討します。「お問い合わせありがとうございました」という固定文だけでも、送信者への確認としては成立する場合が多くあります。
確認 2: 送信元アドレスの設定
次に、管理者宛の通知メールの送信元アドレスが、フォームに入力されたアドレスになっていないかを確認します。返信しやすいようにという意図でそう設定されていることがありますが、送信元は自社の固定アドレスにし、入力されたアドレスは返信先(Reply-To)に置くのが基本です。担当者の使い勝手は変わらず、送信元のなりすましだけを避けられます。
確認 3: 送信記録の偏り
直近の問い合わせ一覧を開き、宛先のドメインが特定の数社に偏っていないか、同じ本文の型が繰り返し現れていないかを見ます。フォームの送信記録をそもそも残していない場合は、記録を残す設定から始めます。記録がなければ、起きたかどうかの判断そのものができません。
あわせて、フォームプラグインのバージョンも確認しておきます。送信処理に関する修正は更新として配られるため、更新が止まっているものは確認対象になります。なお、この確認の途中で管理画面に入れない、画面がエラーで止まるといった別の問題が出たときは、そちらを先に片づけてください。サーバー側の記録はエラーログの読み方の手順で追えます。
対策の順番を間違えない
reCAPTCHA は最初の一手ではない
この話をすると、最初に手が出るのは reCAPTCHA(送信者が機械かどうかを判定する仕組み)や入力チェックの追加です。有効な対策ではありますが、性質としては「自動送信の件数を減らす」ものであって、「送れてしまう構造」を直すものではありません。人力での送信や、より手の込んだ自動化には通り抜けられます。
止める・固定する・抑える の順
- 止める — 自動返信を止められるなら止めます。止められない場合は、本文への入力内容の差し込みを最小限にし、宛先以外は固定文にします
- 固定する — サイトから出るメールの送信元を自社の固定アドレスに統一します。あわせて SPF など、ドメイン側の送信設定を整えておきます
- 抑える — その上で、認証の追加、送信頻度の制限、必須項目の見直しといった入力段階の抑制を重ねます
順番が逆だと、抑制をすり抜けた一通がそのまま踏み台になります。構造を直してから、件数を減らす。この順です。
運用面で最も効くのは、一日あたりの送信件数を把握しておくことです。平常値を知らなければ、増えたことに気づけません。月に一度、記録の件数を数えておくだけでも判断材料になります。
すでに踏み台にされた形跡がある場合は、設定を直して終わりにはなりません。送信評価の回復と、フォーム以外の経路が使われていないかの確認が残ります。後者については、警報が出たときにそれを一件ずつ分類してみた記録が、判断の目安になるはずです。
どこから先は手に負えないか
ここまでの作業は、担当できる範囲がはっきり分かれます。
- 設定画面で完結する範囲 — 自動返信の停止、送信元アドレスの固定、本文テンプレートの見直し、フォームプラグインの更新
- サーバーやドメインの管理権限が要る範囲 — 送信ドメイン認証の設定、送信量の監視、ブロックリストからの解除申請
- 切り分けが要る範囲 — フォーム経由なのか、別の経路からの送信なのかの判定。送信の記録を突き合わせる作業になります
一つ目だけで止まるなら、自社で進められます。二つ目以降に入った時点で、権限を持つ担当者かサーバー側の窓口へ渡したほうが早く終わります。外部に任せる場合に何がどこまで含まれるかは、保守費用の内訳から逆算すると比較しやすくなります。
「これは自分たちの範囲を超えている」と判断できたなら、その確認作業には十分な意味があります。どこで止まったかを言えることが、引き継ぐ側にとって最も役に立つ情報です。
フォームは、外部の人がサイトに触れる数少ない入口であり、同時にサイトが外へ何かを送り出す出口でもあります。入口の守り方だけを考えていると、出口が開いたままになります。自社のサイトが一日に何通のメールを、誰宛に送っているか。その平常値を一度数えておくと、次に何かが変わったときに気づけます。
