2026.04.26

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

安全に生きたい編集部

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

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

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

難易度：★★☆（中級）

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

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

Contents

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

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

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

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

入力項目（名前、メアド、件名、本文、添付）
隠しフィールド（送信先メアド、件名テンプレ等が見えてないか）
CAPTCHAの有無と種類（reCAPTCHA v2/v3、hCaptchaなど）
ファイル添付の許可拡張子・サイズ制限
送信完了時のリダイレクト先
メール送信が同期かバックグラウンドジョブか（タイミング差）

hidden inputに送信先メアドが入ってるパターン、いまだに見かけます。POSTを改ざんすれば任意の宛先に送れちゃう👀

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

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

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

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

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

送信者欄や件名欄で改行コード(rn)を含む値が通ると、Bcc追加・別件名で別人へ送信できるメールヘッダーインジェクションが成立。スパム踏み台化に直結します。

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

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

CAPTCHAやレート制限がないと、botで1秒に何百件も送信される可能性。受信担当者の業務妨害＋送信メアドの評判低下でビジネス影響も大きい。

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

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

本文にHTMLや偽のリンクを仕込んで、受信担当者にクリックさせる手口。社内の人が信用してクリックすると、担当者端末が乗っ取られる足がかりに。社内ネットへの侵入経路にも。

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

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

拡張子チェックが甘いと、invoice.pdf.exeのような二重拡張子偽装や、マクロ付きOfficeファイルでマルウェアを配送できます。ホワイトリスト方式で許可拡張子を絞るのが原則。

添付ファイルって.exeじゃなくてマクロ付きWordとかでも危ないの…！？

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

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

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

仮説を実際に試して確認します。必ず自分の環境か、許可された環境で。

STEP 1

hidden inputの確認

DevToolsでフォームのhiddenを全部見る。送信先・件名テンプレが露出していたら改ざん試験を。

STEP 2

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

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

STEP 3

CAPTCHA回避

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

STEP 4

大量送信テスト

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

STEP 5

添付ファイル攻撃面の確認

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

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

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

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

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

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

① メールヘッダーインジェクションでスパム踏み台化

入力フィールドに改行＋ Bcc: spam-list@… を仕込み、フォームを大量POST。サーバが正規ドメインからスパム送信→IPブラックリスト入り💥

② 受信側担当者へのフィッシング

本文にリンク付きHTMLメールを仕込んで送信。担当者が「お問い合わせ」と思って踏むと社内ネットワーク侵害の起点に🎣

③ 添付ファイル経由マルウェア

.exe→.exe.txt 偽装、マクロ付きOffice、ZIP爆弾などで担当者PC感染を狙う☠️

うわ、自社サーバが攻撃の踏み台になっちゃうの…これ被害者にも加害者にもなるじゃん💧

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

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

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

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

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

攻撃側を理解したら、守る側の打ち手も見えてきます。設計・実装・運用の3レイヤーで考えるのがコツ🛡️

🏗️ 設計レベル

送信先メアドはサーバ側固定（hiddenに置かない）
メール本文・件名は改行・制御文字を除去してからセット
添付不要なら添付機能そのものを廃止

⚙️ 実装レベル

PHPMailer/Symfony Mailer等の堅牢なライブラリ利用
reCAPTCHA v3 + IPレート制限
添付は拡張子＋MIME type＋シグネチャの3点検証
サーバ側でファイルサイズ・種類厳格制限

🔐 運用レベル

SPF・DKIM・DMARC設定で踏み台耐性UP
送信ログ監視（短時間大量送信、異常宛先）
受信側担当者へのフィッシング訓練

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

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

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

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

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

⚠️ よくある落とし穴

送信先メアドをhiddenに置いて改ざんされる古典パターン
CAPTCHAをフロントエンドだけで検証する
担当者へのメールが「ユーザー入力をHTMLレンダリング」してXSS実行

🧰 ツール早見表

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