--- title: "SQLインジェクションとは？仕組みと対策をやさしく理解【SG試験】" description: "SQLインジェクションは、入力値に不正なSQL断片を混入させ、データベースを不正操作する攻撃です。情報漏えい、改ざん、認証回避のリスク、プレースホルダや入力値検証による対策、XSSとの違いをSG試験向けに整理します。SG試験の出題文で迷いやすい判断ポイントも確認します。" last_modified_at: "2026-06-14" canonical_url: "https://stemtazoo.github.io/sg/sql-injection/" section: "sg" --- ## まず結論 - SQLインジェクションとは、**入力値にSQL文を混入させてデータベースを不正操作する攻撃**です。 - SG試験では「**入力値をそのまま使っているかどうか**」を見抜けるかがポイントです。 --- ## 直感的な説明 SQLインジェクションは「注文にこっそり命令を混ぜる」イメージです。 たとえば、ログイン画面で 「ユーザー名」を入力するはずなのに、 ''' 'OR '1'='1 ''' のような不正な文字列を入れると、 システムがそれをSQL文として解釈してしまい、 本来ありえない動き（認証突破など）が起きます。 👉 本来は「値」なのに「命令」として扱われてしまうのが問題です。 --- ## 定義・仕組み SQLインジェクションとは、 > 入力フォームなどにSQL文の一部を埋め込み、 > データベースに対して意図しない操作を実行させる攻撃 です。 典型的な原因： - 入力値をそのままSQLに連結している - 入力チェック（バリデーション）が不十分 基本的な流れ： 1. ユーザーが入力欄に悪意ある文字列を入力 2. そのままSQL文に組み込まれる 3. データベースがそれを実行してしまう 結果として： - 認証回避 - データの漏えい - データの改ざん などが発生します。 --- ## どんな場面で使う？ ### 攻撃されやすい場面 - ログイン画面 - 検索フォーム - 問い合わせフォーム 👉 「ユーザー入力をDBに渡す処理」はすべて対象です。 --- ### 対策が必要な場面 - Webアプリケーション全般 - 外部入力を扱うシステム 👉 SG試験では 「入力値の扱い」が問われることが多いです。 --- ## よくある誤解・混同 ### ❌ よくある誤解 - 「通信を盗み見る攻撃」 - 「プログラムを制限する仕組み」 ### ⭕ 正しい理解 - **入力値を悪用してデータベースを操作する攻撃** --- ### SG試験でのひっかけ SG試験では次のように混同させてきます。 - 「通信内容を検知して遮断」 　→ WAF - 「実行環境を制限する」 　→ サンドボックス - 「入力値を悪用してDB操作」 　→ **SQLインジェクション（これが正解）** 👉 選択肢では 「**SQL文の中に不正な入力を埋め込む**」と書かれていたらSQLインジェクションです。 --- ### 誤解2：SQLインジェクション対策はパケットフィルタリングで十分 これは誤りです。 パケットフィルタリングは、主にIPアドレスやポート番号などの条件で通信を制御する仕組みです。 一方、SQLインジェクションは、**正当なHTTP通信の中に含まれた入力値**が原因で起きます。 そのため、SG試験では次のように切り分けます。 - 「IPアドレス・ポート番号で遮断」→ パケットフィルタリングの説明 - 「入力値を無害化・SQL構造から分離」→ SQLインジェクション対策 ### 誤解3：フィッシングとSQLインジェクションは同じ種類の攻撃 これも誤りです。 フィッシングは、偽サイトや偽メールなどで利用者に情報を入力させる**だます攻撃**です。 SQLインジェクションは、Webアプリの入力処理不備を突いて、データベース命令を不正化する**技術的な注入攻撃**です。 - 「利用者をだまして入力させる」→ フィッシング - 「入力値でSQL文を壊す」→ SQLインジェクション ### 誤解4：サニタイジングはXSS専用で、SQLインジェクションには無関係 これは不正確です。 SG試験の文脈でいうサニタイジング（無害化）は、入力値や出力値を文脈に合わせて安全に扱う考え方です。 SQLインジェクション対策では、第一選択は**プレースホルダ（バインド変数）**ですが、 加えて入力値の検証や無害化を適切に行うことでリスク低減につながります。 ただし、単純な文字除去だけに依存するのは危険です。試験では、 - 「プレースホルダでSQL構造を分離」→ より適切 - 「禁止文字を削るだけ」→ 不十分になりやすい と判断しましょう。 ### 誤解5：プレースホルダだけを考えればよい SQLインジェクション対策では、プレースホルダの利用が実装上の中心対策です。 それに加えて、Webアプリケーションが使うデータベースアカウントには、業務に必要な最小限の権限だけを与えます。 攻撃に成功された場合でも、削除、更新、管理者操作などの不要な権限を持たせていなければ、被害範囲を抑えられます。 SG試験では、プレースホルダは**入力値をSQL文として解釈させない対策**、データベースアカウントの最小権限は**攻撃成功時の被害拡大を抑える対策**として切り分けます。 ## 確認問題（SG試験対策） 次のうち、SQLインジェクション対策として最も適切なものはどれか。 - ア. 入力値をSQL文へ直接連結せず、プレースホルダなどで安全に扱う。 - イ. 利用者全員に管理者権限を与え、エラーを減らす。 - ウ. データベースのパスワードを画面に表示して確認しやすくする。 - エ. 入力値の検査をやめ、SQLエラーの詳細を利用者へ表示する。
▶ クリックして答えと解説を見る（ここを開く） **正解：ア** ### 解説 - ア：SQL文の構造として解釈されないように扱うことが重要です。 - イ：権限過剰で被害が大きくなります。データベースアカウントも必要最小限の権限にします。 - ウ：認証情報の漏えいにつながります。 - エ：攻撃の手掛かりを与え、危険です。 👉 判断ポイント SQLインジェクションは「入力値がSQL文として実行される」ことを防ぐ。
--- ## まとめ（試験直前用） - SQLインジェクション＝**入力値を使ったDB不正操作攻撃** - 原因は「入力値をそのままSQLに使うこと」 - 対策は → プレースホルダ（バインド変数） → 入力チェック → データベースアカウントの最小権限 - SG試験では → 「入力値をSQL文として解釈させない対策」と「被害拡大を抑える対策」を分けて判断する ## 公式情報・参考リンク - [OWASP｜SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection) - [IPA｜安全なウェブサイトの作り方](https://www.ipa.go.jp/security/vuln/websecurity/about.html)