【お問い合わせフォーム編】迷惑送信・入力悪用・個人情報を守る設計｜CTF思考フレームワーク #05

こんにちは、アンペンです！

前回は、検索フォームの入力が画面とサーバーに渡るときに、XSSやSQLiの入口になる話をしました。

今回は、利用者が運営者に直接情報を届けるお問い合わせフォームを見ていきます。送信先がメールや管理画面という「運営者の足元」にあるからこそ、別の種類の攻撃に狙われやすい場所です。

お問い合わせフォームって、ただ運営者にメッセージを送るだけだよね？

そう見えるけど、送信内容がメールや管理画面に直接届くから、スパムやメール改ざんの入口になるんだ。

お問い合わせフォーム、送ったことはあっても『これがセキュリティの話になるの？』とピンと来ない人が多いかもしれません。でもここは、これまでの“利用者が狙われる”話とちょっと毛色が違います。今回ねらわれるのは、なんと運営者のほう。フォームの“向こう側”にいる人が標的になる、という新しい視点を持って読み進めてみてください。きっと、見慣れた問い合わせ画面が少し違って見えてきます。

お問い合わせフォームは「届く先」が攻撃面になる

お問い合わせフォームの入力は、検索フォームと違って画面には残りません。代わりに、運営者のメールアドレスや管理画面に直接届きます。

『画面に残らない』というのが、地味だけど重要なポイントです。検索フォームなら入力結果が自分の画面に出るので、おかしな挙動にも気づけました。でもお問い合わせは、送ったら最後、その後どう処理されるかは利用者からは見えません。見えない場所で何が起きているかを想像する力——それが、この回のかくれたテーマでもあります。

つまり、攻撃者がここを狙うときの相手は、サイト利用者ではなく運営者です。

この『相手が運営者』という視点、最初はピンと来ないかもしれません。でも思い出してみてください。運営者のメールボックスや管理画面は、サイトの“心臓部”にとても近い場所です。そこへ外部の誰もが自由に紙を投げ込めるなら、攻撃者にとってこんなに都合のいい入口はありません。

ここがこれまでの回との大きな違いです。検索フォームでは、入力は画面に返ってきて“利用者自身”に跳ね返りました。でもお問い合わせの入力は、画面には残らず、運営者のメールボックスや管理画面という“奥の部屋”に届きます。つまり攻撃者にとってフォームは、『運営者の机の上に、好きな紙を直接置ける投函口』に見えているわけです。だから守りの発想も、利用者向けとはガラッと変わってきます。

図解：お問い合わせの送信経路

普通の問い合わせと、悪意ある送信を比べると、たどる経路は同じでも、結果に大きな差が生まれます。

言いかえると、フォームというのは“来た紙を疑わずに受け取る”という、もともと無防備な性質を持っています。だからこそ、受け取る側で『この紙は信用できるか』をきちんと仕分ける関所が必要になるわけです。

CSRFは少しイメージしづらいので、もう少しかみくだきますね。たとえばあなたが、あるサイトにログインしたまま、別のページを開いていたとします。そこに仕掛けられた“見えないボタン”が、あなたのブラウザを使って、あなたの名前で勝手にフォームを送信してしまう——これがCSRFです。あなた自身は何も悪いことをしていないのに、あなたの操作として記録されてしまうのが怖いところ。だから守る側は『本当にこのサイトの画面から送られた操作なのか？』を毎回たしかめる仕組みを用意します。

お問い合わせフォームから狙われる3つの攻撃

お問い合わせ周りの代表的なリスクは、大きく3つです。『大量に送りつける』『他人になりすまして送らせる』『メールの宛先をこっそり書き換える』。どれも“フォームが正しく動いているのに”起きるのがポイントで、バグというより、入口を絞っていない設計のゆるさが原因なんです。一つずつのぞいていきましょう。

代表的なリスク

• スパム大量送信：自動化されたボットが、宣伝・詐欺リンクを大量に投げ込み、運営者の受信箱を埋める
• CSRF：ログイン中の利用者を経由して、本人の意思に反した送信が行われる
• メールヘッダー改ざん：入力欄に改行と追加ヘッダーを混ぜることで、別の宛先にもメールが届くようにされる

これらは、フォーム自体は「正しく動いて」いても起こります。攻撃者は仕様の隙間や、運営者側の処理を狙ってきます。

ここ、すごく大事な考え方です。私たちはつい『バグがあるから攻撃される』と思いがちですが、お問い合わせフォームの攻撃の多くは、プログラムが仕様どおり完璧に動いていても成立します。なぜなら攻撃者が突くのは“バグ”ではなく、『誰でも・何でも送れてしまう』という仕様そのものの緩さだから。だから直し方も、『コードのバグ取り』ではなく『入口に関所を設ける』という発想になるんです。

3つの中でも、初めて聞くと驚くのが『メールヘッダー改ざん』かもしれません。仕組みはこうです。フォームの名前欄やメール欄に、こっそり“改行”と「Bcc: 知らない宛先」のような一文を紛れ込ませる。すると、システムがその入力をメールの設定欄にそのまま組み込んでしまった場合、本来の運営者だけでなく、攻撃者が指定した相手にもメールが飛んでしまうんです。たった一つの改行が、メールの“宛名書き”を乗っ取ってしまう——これが「CRLFインジェクション」と呼ばれる手口です。

名前を書く欄で、メールの宛先まで変えられちゃうの？さすがに大げさじゃない？

それが本当に起きるんだ。コンピュータは『改行のあとに書かれた指示』を律儀に読んでしまうことがあるからね。だから守る側は、入力に紛れた改行をきっぱり捨てる。たった一手間だけど、これでメールの宛名を勝手にいじられる道をふさげるんだよ。

CTFでやってみよう：送信先と入力の関係を観察する

演習でフォームのソースをのぞいてみると、『お、CSRFトークンが入ってるな』『CAPTCHAが動いてるな』と、守りの“仕掛け”が見えてきます。逆に何も入っていなければ、それは無防備のサイン。こうして観察できるようになると、守る側の発想がぐっと身近になります。では、その守りをどう組み立てるか。キーワードは『入口・経路・出口』の3点です。

守る側なら、入口・経路・出口の3点で守ろう

お問い合わせフォームの守り方は、「入口で絞り込む・経路を本人だけに限定する・出口で安全に処理する」の3段階で考えると整理しやすくなります。

お問い合わせは「運営者に届く」から、守る方向も違うんだね。

そう。利用者を守る画面と、運営者を守るフォーム、両方の視点を持てると強いよ。

ここまでをひと言でまとめると、お問い合わせフォームは『運営者の机に直結した投函口』。だから守りは、利用者を守るときとは別の引き出しを開ける必要があります。そして大切なのは、どれか一つではなく、入口・経路・出口の対策を“重ねて”使うこと。関所は一つより、いくつもあるほうが安心ですよね。

まとめ：お問い合わせフォームは「運営者の入口」

今日の持ち帰りは『フォームの“向こう側”を想像する』ことです。入力がどこに届き、誰の手元で、どんなふうに使われるのか。そこまで思い描けると、入口（CAPTCHA）・経路（CSRFトークン）・出口（改行除去）という3段の守りが、自然と腑に落ちるはずです。逆に、向こう側を想像できないと、どんな対策も“とりあえず入れただけ”になってしまいます。

次回は、ユーザーが何かを送るシリーズの続きとして、ファイルアップロードを扱います。「ただ画像を送るだけ」が、なぜRCEの入口になりうるのかを見ていきましょう。

次に読みたい記事

参考資料