2026.04.26 2026.05.02

【お問い合わせフォームの危険】スパム・CSRF・メール改ざん対策｜CTF思考フレームワーク #05

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　Webフォーム編　#05 / 公開中 10記事　→　シリーズ一覧を見る →

お問い合わせフォームって、内容書いて送るだけのシンプル機能。でも攻撃者にとってはメール踏み台・スパム送信・情報窃取の入口なんです📨

難易度：★★☆（中級）

メールヘッダーインジェクション、添付ファイル攻撃、スパム悪用が中心🔬

「送信しました」とサンクスページが出るだけのフォームに、これだけの攻撃面があります。受信側の運用担当者を狙う攻撃も多いので要注意⚠️

この記事の難易度

難易度：★★☆（やさしめ）　／　所要：10〜12分　／　前提：#01〜#04の内容

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者ならどう考える？
🔬 検証フェーズ：実際に試す手順
⚔️ 攻撃フェーズ：攻撃者ならこう攻める
🛡️ 防御フェーズ：どう守る？
🛡️ 今日からできる対策ツール
⚠️ よくある落とし穴
📚 もっと深く学びたい人へ
🤝 大事なお約束
📚 次に読みたい

👀 観察フェーズ：まず何を見る？

お問い合わせって地味だけどサーバが直接外部にアクセスする機能。狙われると怖いんだ。

お問い合わせフォームって地味だけど、サーバが直接外部にアクセスする機能。送信先のメアドへ実際にメールを飛ばす仕組みが裏で動いているので、悪用されると怖いんだよ。😿

お問い合わせフォームは「メール送信機能」と「ファイル受信機能」がセットになりがち。攻撃者は送信先・添付・隠し項目を順に観察します。🔍

入力項目（名前、メアド、件名、本文、添付）
隠しフィールド（HTMLの type="hidden" 入力欄。画面に出ないが送信される項目）── 送信先メアドや件名テンプレ等が見えてないか
CAPTCHA（人間か機械かを判定する仕組み）の有無と種類（reCAPTCHA v2/v3、hCaptcha など。v3は見えない判定型）
ファイル添付の許可拡張子・サイズ制限（.exe禁止か、何MBまでか。ここがゆるいとマルウェア配送の入口に）
送信完了時のリダイレクト先（オープンリダイレクト＝外部URLにそのまま飛ばせる脆弱性の温床）
メール送信が同期（送信中はレスポンスを返さない）かバックグラウンドジョブ（裏のキューで送る）か（タイミング差から内部構造が推測できる）

HTMLソースを Ctrl+U で開いて、<input type="hidden" name="to" value="..."> のような隠しフィールドに送信先メアドが入っているパターン、いまだに見かけます。これは POST リクエストを書き換えれば任意の宛先に送れちゃう状態です。👀

送信先メアドが隠しフィールドに書かれてるって…そんなの普通なの！？💧

🤔 仮説フェーズ：攻撃者ならどう考える？

“自社のメールサーバから攻撃が出る”のが最悪パターン。送信元のレピュテーションも傷つくよ。

お問い合わせフォームはスパム踏み台・フィッシング送信元・マルウェア入口になりやすい場所。代表的な4つの仮説を、一つずつ見ていきます。

✉️ 仮説①：メールヘッダーに改行を仕込めるか

送信者欄や件名欄に改行コード（\r\n＝メールヘッダーを区切る制御文字）を含む値が通ると、Bcc追加・別件名で別人へ送信できるメールヘッダーインジェクション（メールヘッダに不正な行を注入する攻撃）が成立します。1985年から知られている古典脆弱性で、入力検証を1個サボると今でも刺さります。

え、件名に改行入れるだけで宛先追加できちゃうの…？こわすぎ💧

🚫 仮説②：CAPTCHAなし＝botで無限送信

CAPTCHAやレート制限（短時間の連続リクエストを制限する仕組み）がないと、botで送信ファームを構築される可能性。受信担当者の業務妨害に加え、サーバから大量送信した結果送信元IPがブラックリスト入りして、まっとうな業務メールも届かなくなります。

うわ、お問い合わせフォームがスパム発射台になっちゃうの！？

🎣 仮説③：受信側担当者へのフィッシング

本文にHTMLや偽のリンクを仕込んで送信。担当者が「お問い合わせだから」と信用してクリックすると、担当者端末が乗っ取られる足がかりに。社内から見ると”正規のお問い合わせ通知メール”の体裁なので、標的型攻撃の入口として悪用されます。

受信する担当者の方を狙うのか…考えもしなかった

📎 仮説④：添付ファイルでマルウェア配送

拡張子チェックが甘いと、invoice.pdf.exe（ピリオドが2個ある二重拡張子偽装）や、マクロ付きOfficeファイル（Wordの “コンテンツの有効化” を押させて悪意あるVBAを実行させる手口）でマルウェアを配送できます。MIMEタイプ（ファイル種別を示すメタ情報）だけ見て安心している実装は要注意。

お問い合わせフォーム＝「サーバが外部にメールを送る」機能。だから、入力検証＋CAPTCHA＋拡張子制限がセットで必要なんです。💡

🔬 検証フェーズ：実際に試す手順

お問い合わせの検証は少量から段階的に。実サーバを動かす（＝本物のメールが送られる）ので、慎重にね。😿

お問い合わせの検証は少量から段階的に。実サーバを動かすので慎重にね。

仮説を立てたら、ここからは実際に動かして反応を見るフェーズ。必ず自分の環境（自分が立てたお問い合わせフォームや検証用環境）か、明確に許可された場所でだけ実施してください。他人のフォームに勝手に投げると不正アクセス禁止法違反＋業務妨害になります。

名前欄に Taro\r\nBcc: attacker@example.com のように改行＋ヘッダを仕込み、自分宛に届いたメールのヘッダで Bcc が混入したかを確認。混入してたらメールヘッダーインジェクション成立です。

名前欄に「TaronBcc: attacker@example.com」のように改行＋ヘッダーを仕込み、自分宛に届いたメールのヘッダーで Bcc が混入したか確認。

送信POSTを直接 curl（コマンドラインからHTTPリクエストを送るツール）でリプレイ（再送）。CAPTCHAパラメータを抜いても送信できれば、サーバ側で検証していない=実質バイパス可能です。

送信POSTを直接Burpリプレイ。CAPTCHAパラメータ抜きでも送信できれば実質バイパス可能。

レート制限の有無を確認。同IPから10連続送信して受け付けられるなら、踏み台化のリスクあり。多くのサービスでは「1分に1回まで」「5分に5回まで」のような制限が標準です。

レート制限の有無確認。同IPから10通連続送って受け付けられるなら、踏み台化のリスクあり。

.txt偽装した実行ファイル、ZIP爆弾（解凍すると数十GBに膨らむ細工された圧縮ファイル）、巨大ファイルでサーバ反応を見る（必ず自分のサーバのみ）。サイズ・拡張子・MIMEタイプが多層で検証されているかを確かめます。

.txt偽装した実行ファイル、ZIP爆弾、巨大ファイルでサーバ反応を見る（自分のサーバのみ）。

改行コード一個でメール挙動が変わるって、目に見えないからこわい…💧

そう、改行・制御文字を弾くのが基本。フレームワークやライブラリ任せにせず、自分で確認しよう。

そう、改行・制御文字を弾くのが基本。フレームワークやライブラリ任せにせず確認しよう。

⚔️ 攻撃フェーズ：攻撃者ならこう攻める

“なぜ通るか”を理解するのがゴール。送信元の信頼がかかっているから、怖いよね。

検証で「ここ弱いな」と判断したら、実際の攻撃に移ります。お問い合わせフォームでよくある攻撃はこの3パターン。

検証で「ここ弱いな」と判断したら、ここからは攻撃のパターンを見ていきます（あくまで防御のため！）。お問い合わせフォームでよくある攻撃はこの3パターンです。

結果として、こんな”フラグ”を取られちゃうイメージ：

POST /contact
name=Taro%0ABcc:attacker@evil.com
→ 送信メールに Bcc 混入
CTF{email_header_injection}

お問い合わせフォーム1個のミスで「自社のメールサーバを踏み台にされる」のが最大リスクです。🚨

🛡️ 防御フェーズ：どう守る？

やっとお待ちかね、守る側の打ち手。SPF/DKIM/DMARC＋CAPTCHA＋拡張子制限が三種の神器だよ。

攻撃側を理解したら、守る側の打ち手も自然と見えてきます。お問い合わせフォームの防御は、設計・実装・運用の3レイヤーで考えるのがコツ。1枚目で漏れても2枚目、3枚目で止める”多層防御“の発想です。🛡️

🏗️ 設計レベル

送信先メアドはサーバ側で固定（hidden input に置かない＝改ざんできないようにする）

メール本文・件名は改行・制御文字を除去してからセット（メールヘッダーインジェクション対策の本丸）

添付不要なら添付機能そのものを廃止（攻撃面を減らすのが最強の防御）

⚙️ 実装レベル

PHPMailer / Symfony Mailer 等の堅牢なライブラリ利用（自分で mail() 関数を直接叩かず、検証実績のある実装に任せる）

reCAPTCHA v3（行動からスコアで判定する見えないCAPTCHA）＋ IPレート制限（同一IPからの連続送信を制限）

添付は拡張子＋MIMEタイプ＋シグネチャ（ファイル先頭の数バイト＝マジックナンバー）の3点検証（拡張子だけでは偽装を防げない）

サーバ側でファイルサイズ・種類厳格制限

🔐 運用レベル

SPF / DKIM / DMARC（送信ドメイン認証の3点セット。メールが本物かを受信側で検証する仕組み）設定で踏み台耐性UP

送信ログ監視（短時間大量送信、異常宛先）
送信ログ監視（短時間大量送信、異常宛先（社外メアドへの大量Bcc等）を検知してアラート）

受信側担当者へのフィッシング訓練
受信側担当者へのフィッシング訓練（人間側の防御。送信元を疑う癖をつける）

なるほど…入力検証＋送信認証＋運用監視を全部やる必要があるんだね。どこか1個抜けると突破されるってことか！

その通り。送信元の信頼を守るためにDMARCまでセットでやるのが今の標準だよ🛡️

🛡️ 今日からできる対策ツール

パスワードの使い回しや手動管理はどんなに気をつけても限界があります。🔑 パスワード管理ツール「ワンパス」なら、複雑なパスワードを安全に保管して「1つのマスターパスワード」だけ覚えられるので、今日から始める防御策としてしっくりきます。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

送信先メアドをhiddenに置いて改ざんされる古典パターン
送信先メアドをhiddenに置いて改ざんされる ─ 古典中の古典。サーバ側で固定値を持つのが鉄則。フォームの値は全て”敵”と思って扱う。

CAPTCHAをフロントエンドだけで検証する ─ JSの判定を消されたら通ってしまう。サーバ側でreCAPTCHAトークンを必ず検証する。

担当者へのメールで「ユーザー入力をHTMLレンダリング」してXSS実行 ─ Webメーラー経由で受信時にスクリプトが走るパターン。プレーンテキスト送信か、HTML送信時は厳密にエスケープ。
担当者へのメールが「ユーザー入力をHTMLレンダリング」してXSS実行

ツール	何ができる	使いどころ（やさしい解説）
Burp Suite	POST改ざん・リプレイ	検証フェーズ全般（送信内容を書き換えて反応を見る、Webセキュリティの定番ツール）
curl	コマンドラインから直接POST	CAPTCHA抜きで送れるか確認（ブラウザを介さずサーバへ素のリクエストを送れる）
swaks	SMTPテストツール	送信メール検証（メール送信プロトコルを直接喋って、ヘッダ混入の確認に使える）
MXToolbox	SPF/DKIM/DMARC確認	運用フェーズ（自分のドメインの送信認証設定が正しく入っているかWebで一発確認）

ツール	何ができる	使いどころ
Burp Suite	POST改ざん・リプレイ	検証フェーズ全般
curl	生HTTPリクエスト送信	ヘッダーインジェクション検証
MXToolbox	SPF/DKIM/DMARC確認	運用レベル防御
VirusTotal	添付ファイル検査	受信時防御

Webセキュリティを「趣味」から「仕事」に変えたい方へ。🎓 ササエルはインフラエンジニアに特化したオンラインスクールで、セキュリティ設計の基礎から体系的に学べます。お問い合わせフォーム1つでも、設計→実装→運用の全体像で語れるようになると、現場での説得力がぐっと変わります。

Webセキュリティを「趣味」から「仕事」に変えたい方へ。🎓 ササエルはインフラエンジニアに特化したオンラインスクールで、セキュリティ設計の基礎から体系的に学べます。

📚 もっと深く学びたい人へ

体系的に攻撃と防御の両面を学びたいなら、『ホワイトハッカー入門第2版』（IPUSIRON 著）が分かりやすい入口です。攻撃の仕組みを”手を動かしながら“理解する構成で、本記事の検証フェーズと相性抜群。📚

ホワイトハッカー入門第2版

Amazon

＼楽天ポイント4倍セール！／

楽天市場

Yahooショッピング

ポチップ

🤝 大事なお約束

必ず守ってね

この記事の手法は、必ず自分の環境か、許可された CTF・脆弱性報奨金プログラム（HackerOne, Bugcrowd 等。”見つけたら報告すれば報奨金がもらえる”公式ルートのこと）で試してください。他人のサービスに無断で攻撃を仕掛けるのは不正アクセス禁止法違反、立派な犯罪です。お問い合わせフォームは特に業務妨害罪にも触れる可能性があるので、慎重に。学んだ知識は守る側で活かすのが、この記事の唯一にして最大の約束です。🤝