最終更新日：2026年9月11日

fe fe-technology database security

まず結論

SQLインジェクションは、利用者の入力がSQL文の一部として解釈されることで、データベースへの問い合わせや操作を不正に変えられてしまう攻撃です。

FE試験では、選択肢に 「SQL」「データベース」「問い合わせ」「入力文字が特別な意味をもつ」 といった手掛かりがあれば、まずSQLインジェクションを疑います。

対策として 「プレースホルダ」「プリペアドステートメント」「パラメータ化クエリ」 が出てきたら、SQLインジェクション対策を第一候補にします。

特に重要なのは、XSSなどの別の攻撃と「どこで入力が解釈されるか」を切り分けることです。

直感的な説明

Webアプリケーションでは、利用者が入力した文字列を使ってデータベースを検索することがあります。

たとえば、利用者が入力した名前をそのままSQL文につなげる仕組みを考えます。

SELECT * FROM users WHERE name = '入力された名前';

普通の名前が入力されるだけなら問題はありません。

しかし、入力欄にSQLで特別な意味をもつ記号や文字列が入り、それをそのままSQL文に組み込むと、アプリケーションが意図していないSQL文として解釈されることがあります。

つまり、SQLインジェクションは、

入力データとして扱うはずの文字が、SQLの命令の一部として扱われてしまう

ことが問題です。

対策の直感はシンプルです。

SQLの命令と、利用者が入力したデータを分ける

この考え方を実現する代表的な仕組みが、プレースホルダを使ったプリペアドステートメントです。

定義・仕組み

SQLインジェクションでは、Webアプリケーションなどが利用者の入力をもとにSQL文を組み立てるとき、その入力を安全に扱えていないことが攻撃につながります。

攻撃が成立すると、意図しない検索や更新、削除などのデータベース操作が行われるおそれがあります。

試験では、細かなSQL文を暗記するよりも、次の流れを理解しておくと判断しやすくなります。

  1. 利用者が文字列を入力する
  2. アプリケーションがその入力を使ってSQL文を組み立てる
  3. 入力中の文字がSQLの一部として解釈される
  4. 本来とは異なるデータベース操作が実行される

対策では、利用者の入力をSQL文の構造として解釈させないことが重要です。

プレースホルダとは？

プレースホルダは、SQL文の中で後から値を入れる場所を示す目印です。

例えば、次の ? がプレースホルダです。

SELECT * FROM users WHERE id = ?

この段階でSQL文の構造を決めておき、? の部分には後から入力値を「データ」として渡します。

SQLの構造        SELECT * FROM users WHERE id = ?
                                      ↓
入力データ                            123

ポイントは、入力値をSQL文の文字列へ直接つなげないことです。

そのため、試験では次のように結び付けます。

プレースホルダ
    ↓
SQLの命令と入力データを分離する
    ↓
SQLインジェクション対策

プレースホルダを利用してSQL文を実行する方法は、プリペアドステートメントやパラメータ化クエリと呼ばれます。

FE試験では、「入力された文字をSQLで特別な意味をもつ文字として解釈させない」といった説明も、SQLインジェクション対策の手掛かりになります。

IPAの一次情報で確認する

IPAの「安全なウェブサイトの作り方」では、SQLインジェクションの根本的な対策として、SQL文の組み立てをプレースホルダで実装する方法が示されています。また、プレースホルダへ実際の値を割り当てる処理をバインドと説明しています。

試験対策では、次の対応関係を押さえておけば十分です。

SQL文の雛形
    ＋
プレースホルダ
    ＋
入力値をバインド
    ↓
入力値をSQLの命令として扱わせない
    ↓
SQLインジェクション対策

より詳しい仕組みは、IPAの別冊「安全なSQLの呼び出し方」で、文字列連結・静的プレースホルダ・動的プレースホルダの違いまで整理されています。

このテーマは、基本情報技術者試験のデータベースと情報セキュリティの両方に関係します。公式の出題範囲やシラバスは、IPA：基本情報技術者試験 から確認できます。

科目Aでどう出る？

科目Aでは、SQLインジェクションそのものの定義だけでなく、他の攻撃への対策と混ぜて出されることがあります。

まず「何が解釈される場所なのか」を見ます。

問題文・選択肢の手掛かり 疑う攻撃・対策
SQL、データベース、問い合わせ SQLインジェクション
プレースホルダ、プリペアドステートメント SQLインジェクション対策
HTML、スクリプト、ブラウザ表示 XSS
../、ファイル、ディレクトリ ディレクトリトラバーサル
入力サイズ、メモリ領域 バッファオーバーフロー

入力対策が並んだときの判断フロー

入力に対する対策が複数並んでいるときは、「何を解釈させないための対策か」を見ると切り分けやすくなります。

入力対策の選択肢が並ぶ
↓
何を解釈させない対策かを見る

SQLとして解釈させない
→ SQLインジェクション対策

HTML・スクリプトとして解釈させない
→ XSS対策

../ などのファイルパスを拒否する
→ ディレクトリトラバーサル対策

大きすぎる入力を拒否する
→ バッファオーバーフロー対策

つまり、「入力を安全にしているから全部同じ対策」と考えず、入力がどこで、何として使われるのかを確認するのがポイントです。

SQLインジェクションを見分けるときは、

「その入力はデータベースへ渡され、SQLとして解釈されるのか？」

と考えると選択肢を切りやすくなります。

また、対策を問われたときは、

「プレースホルダ」→ SQLインジェクション対策

を強い対応関係として覚えておくと判断しやすくなります。

科目Bでどう使う？

科目Bの情報セキュリティでは、攻撃名を暗記しているだけでなく、状況に合った対策を選ぶことが重要です。

SQLインジェクションでは、次の順番で考えます。

  1. 利用者から入力を受け取っているか
  2. その入力を使ってデータベースへ問い合わせているか
  3. 入力値がSQL文の構造に影響できる状態になっていないか
  4. 入力値とSQL文を分けて扱う対策になっているか

特に、HTML表示を安全にする処理が書かれていても、それだけではSQLインジェクション対策にはなりません。

「どこで入力が解釈されるか」→「その場所に合った対策か」 の順で確認するのがポイントです。

よくある誤解・混同

プレースホルダは「入力チェック」そのものではない

プレースホルダの重要な役割は、単に入力文字を検査することではありません。

SQLの構造と入力データを分離し、入力値をSQLの命令として解釈させないことがポイントです。

「危険そうな文字だけを削除する」と覚えるより、命令とデータを分けると理解した方が試験でも応用しやすくなります。

XSSとの違い

XSSは、主に入力された文字列がHTMLやスクリプトとしてブラウザで解釈されることを悪用する攻撃です。

SQLインジェクションは、入力された文字列がSQLの一部としてデータベース側で解釈されることを悪用します。

  • SQLとして解釈される → SQLインジェクション
  • HTML・スクリプトとして解釈される → XSS

と切り分けます。

ディレクトリトラバーサルとの違い

ディレクトリトラバーサルは、../ などを利用して、本来アクセスできないファイルやディレクトリへアクセスしようとする攻撃です。

ファイルパスや上位ディレクトリが問題になっているなら、SQLインジェクションではありません。

バッファオーバーフローとの違い

バッファオーバーフローは、確保されたメモリ領域を超えるデータを書き込むことで、不正な動作を引き起こす攻撃です。

入力文字列の「意味」ではなく、入力サイズやメモリ領域が手掛かりになります。

「入力チェックをすれば何でも同じ」ではない

試験では、入力に対する対策が複数並ぶことがあります。

重要なのは「入力をチェックしているか」だけではなく、どの攻撃を防ぐための処理なのかを見ることです。

  • SQLの構造に影響させない
  • HTMLとして実行させない
  • 不正なファイルパスを受け付けない
  • 過大な入力を受け付けない

では、それぞれ守っている対象が違います。

まとめ（試験直前用）

  • SQLインジェクション：入力値によってSQL文を不正に操作する攻撃
  • プレースホルダ／プリペアドステートメント：SQLの命令と入力データを分ける代表的な対策
  • SQL・DB・問い合わせが出たらSQLインジェクションを疑う
  • HTML・スクリプトならXSS、../・ファイルパスならディレクトリトラバーサル
  • 判断に迷ったら、「入力がどこで、何として解釈されるか」を見る

© 2024-2026 stemtazoo. All rights reserved.