【検索フォーム編】入力欄から考えるXSS・SQLiの入口と守り方｜CTF思考フレームワーク #04

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

前回は、パスワード再設定機能で「画面の返事」と「リセットリンクの作り」の両方を整える話をしました。

今回は、誰もが毎日使う検索フォームを見ていきます。「ただ検索するだけ」の入力欄が、なぜ攻撃の入口になってしまうのかを学びましょう。

検索フォームに文字を打ち込むだけだよね？何が危ないの？

入力した文字が、画面とサーバーにそのまま渡される場面が多いから、扱い方を間違えるとXSSやSQLiの入口になるんだ。

検索ボックスって、たぶんネットで一番よく使う入力欄ですよね。『調べたい言葉を打つだけ』のあの何気ない欄が、実はWebセキュリティの超重要テーマ——XSSやSQLインジェクション——の入口になりやすいんです。今日は「なぜそんなことになるのか」を、むずかしい用語をかみくだきながら一歩ずつ追いかけていきます。身構えずに読んでくださいね。

検索フォームは「入力の通り道」が短い場所

検索フォームでキーワードを入力して送信すると、入力した文字は2つの場所に渡されます。

• 画面：「『キーワード』の検索結果」のように、入力をそのまま表示することが多い
• サーバー：データベース検索や外部APIに、入力を渡して結果を取り出す

この「画面」と「サーバー」の両方で、入力をどう扱うかが安全性を決めます。何も処理せずに使うと、入力に混ざった攻撃文字列がそのまま動いてしまいます。

検索フォームがちょっと特別なのは、打ち込んだ言葉が“すぐ目の前に返ってくる”ところです。「『ねこ』の検索結果」のように、入力がそのまま画面に表示されますよね。この『入力 → そのまま出力』という最短ルートこそ、攻撃者にとって一番おいしいポイント。自分が送った文字が画面に出るなら、そこに“ただの文字”じゃないものを混ぜたらどうなる？——そう考えるのが攻撃者の発想なんです。

図解：検索キーワードが画面に表示されるまで

普通のキーワード(「ねこ」)と、HTMLタグ入りのキーワード(「<b>test</b>」)を比べてみると、扱いの差がはっきり見えます。

『エスケープ』という言葉、ここで一度しっかり押さえておきましょう。むずかしく聞こえますが、やっていることは“記号の牙を抜く”だけ。たとえば「<」をそのまま出すとブラウザはタグの始まりだと勘違いしますが、これを安全な表記に置き換えてあげれば、ただの「小なり記号」として表示されます。料理でいう『下ごしらえ』みたいなもので、危ない部分をあらかじめ無害にしておく作業だと思ってください。

検索フォームから狙われる代表的な攻撃

検索フォームから狙われる攻撃は1つではありません。画面表示・データベース・リダイレクトなど、それぞれの経路で別の攻撃が成立します。

『攻撃が3つもあるの？覚えるの大変そう…』と思うかもしれません。でも安心してください。この3つは、根っこがぜんぶ同じなんです。すなわち「入力をそのまま使ってしまう」こと。表示で悪さをすればXSS、データベースで悪さをすればSQLi、転送先で悪さをすればオープンリダイレクト——出口が違うだけで、原因は一つ。だから対策も『出口ごとにちゃんと処理する』という一本の筋でつながっていきます。

代表的な3つの攻撃パターン

• XSS(クロスサイトスクリプティング)：キーワードに混ぜたスクリプトが、検索結果画面でそのまま動いてしまう
• SQLi(SQLインジェクション)：キーワードに混ぜた文字が、データベース命令の一部として解釈されてしまう
• オープンリダイレクト：「検索後に飛ばす先」のURLパラメータに、外部の悪意あるサイトを入れられる

OWASP Top 10では、これらは「インジェクション」「クロスサイトスクリプティング」として長く上位に登場し続けている、Webセキュリティの中心テーマです。

XSSって名前はよく聞くけど、結局なにが起きるの？

ざっくり言うと『他人のブラウザで、攻撃者が書いたプログラムが動いてしまう』ことだよ。たとえば検索結果に紛れ込ませたスクリプトが、その画面を見た人のログイン情報をこっそり盗む——なんてことが起きうる。検索欄が“他人のパソコンを操る遠隔スイッチ”に変わってしまうイメージだね。

ここまで読んで『じゃあ自分の目で確かめてみたい』と思ったら、いい流れです。ただし大前提として、試すのは必ず自分の演習環境かCTFだけ。本物のサイトで攻撃文字列を打ち込むのは、たとえ出来心でも法律に触れます。安全な砂場の中で、入力がどう扱われるかをじっくり観察してみましょう。

CTFでやってみよう：検索結果を観察する

演習をやってみると、『普通の文字はそのまま、タグを入れると太字になっちゃった！』という瞬間に出会えるはずです。その一瞬こそ、入力が“文字”ではなく“命令”として扱われた証拠。怖がる必要はなくて、ここが腹落ちすれば守り方もスッと入ってきます。キーワードはたった一つ、『出力するその瞬間に処理する』です。

守る側なら、出力先ごとに正しく処理しよう

検索フォームを守るときは、「入力を信用しない」ではなく、「出力するときに、出力先に合わせた処理を必ずする」と覚えるのがコツです。

「入力をチェックする」より「出力で処理する」の方が確実なんだね。

そう。入力チェックも大事だけど、最終的な防御は『出力するその瞬間』の処理だと覚えておくと安心だよ。

もう一つだけ大事なコツを。守りは“多重”にするのが基本です。出力エスケープをしていても、CSP（決められた場所のスクリプトしか動かさない仕組み）をかけておけば、万一エスケープ漏れがあっても被害を食い止められます。鍵を一つではなく二つ三つかけておく感覚ですね。「ここさえやれば100点」という単一の対策はない、と覚えておくと安心です。

まとめ：検索フォームは「画面」と「サーバー」の両方を守る

今日の持ち帰りは『入力は信じず、出力で守る』。入り口でがんばって怪しい文字をはじくより、出ていくその瞬間に、出力先（画面・データベース・転送先）に合った処理をするほうが、ずっと確実で漏れがありません。しかもこの考え方は検索フォームに限らず、コメント欄でもプロフィール欄でも、入力を扱うあらゆる場所でそのまま使えます。

検索フォームは便利な機能ですが、入力を「ただの文字」として正しく扱わないと、画面とサーバーの両方が攻撃の踏み台になります。次回は、もう一歩進んで利用者と運営者が直接やりとりするお問い合わせフォームを題材にします。

次に読みたい記事

参考資料