基本情報 令和6年度 科目A 問10：テクノロジ系に関する問題

答えは d です。

SQLインジェクション＝Webサイトの入力欄に悪意あるSQL文（DBへの命令）を混ぜて、データベースを盗み見る攻撃。

対策は プレースホルダ＝SQL文の中に「ここに値を入れる箱」を作っておき、ユーザーの入力をただのデータとして扱う仕組み。

たとえば「お名前は○○」の○○に「'; DROP TABLE users;--」って書かれても、プレースホルダを使えば文字列としてしか扱わないから、命令として実行されません。

👉 覚え方：プレースホルダ＝場所取り＝ユーザー入力を“ただの文字”扱いにする。

ほかの選択肢：a URLチェック＝オープンリダイレクト対策／b ファイル名直接指定回避＝ディレクトリトラバーサル対策／c スタイルシート制限＝CSS injection対策。全部別の攻撃の対策。

なぜこれが正解か

正解は d。SQLインジェクションは、ユーザー入力をSQL文に文字列連結することで、攻撃者が任意のSQL命令を実行可能になる脆弱性。プレースホルダ（プリペアドステートメント／パラメータ化クエリ）を使うと、SQL文の構造とパラメータが分離され、入力値はリテラル（データ）としてのみ扱われるため、構文として解釈されず根本的に防げる。

各選択肢の解説

• a URLスキーマ制限：オープンリダイレクトやXSS（javascript:スキーマ）対策。
• b ファイル名直接指定回避：ディレクトリトラバーサル（パストラバーサル、../による上位ディレクトリアクセス）対策。
• c 任意CSS取り込み禁止：CSSインジェクション／CSPバイパス対策。

覚え方・ひっかけ注意

SQLインジェクション対策の本命＝プレースホルダで即答可。エスケープ処理は次善策（DB方言や文字コードで漏れが出る）、WAFは多層防御の補助であって根本対策ではない。最小権限の原則（DBユーザーに必要最小限のSELECT等のみ付与）と組合せると被害を限定できる。

理論的背景・仕組みの詳細

プレースホルダはSQL文の準備（Prepare）と実行（Execute）を分離する仕組み。Prepare段階でDBサーバーが構文解析・実行計画作成を行い、Execute段階で値のみを渡すため、値がSQL構文の一部として再解釈されることがない。実装方式は2系統：

• サーバサイドプリペアドステートメント：Prepare文をDBに送り、実行計画をキャッシュ。性能向上効果もあり。
• クライアントサイドエミュレーション：ドライバ側でエスケープ処理してSQL文を組み立て。一部レガシードライバで採用。

PDOのデフォルトは ATTR_EMULATE_PREPARES=true でクライアントサイドだが、セキュリティ的にはサーバサイド推奨。

実務での使われ方・関連規格/法令

言語別の標準API：

• Java：PreparedStatement（JDBC）、JPA `:param` バインド、MyBatis `#{param}`（`${}`は危険）
• PHP：PDO prepared statements、mysqli prepared statements
• Python：DB-API 2.0 `cursor.execute(sql, params)`、SQLAlchemy text() bindparams
• C#：SqlCommand with SqlParameter、Dapper の `@param`
• Node.js：mysql2/promise の `?` プレースホルダ、Knex/Prismaのバインド
• ORM：Active Record（Rails）、Sequelize、Drizzle、Prisma は基本的に安全だがraw SQL注入箇所は要レビュー

標準・ガイドライン：OWASP Top 10 2021 A03:2021 Injection（旧A1から順位低下したが依然重要）、OWASP ASVS V5（Validation, Sanitization and Encoding）、CWE-89（SQL Injection）、PCI DSS v4.0 6.2.4、経産省「安全なウェブサイトの作り方」（IPA）。日本では2005年〜カカクコム・GENO事件以降、大規模情報漏えいの主要原因として継続的に発生。

試験での位置づけ

FE科目Aセキュリティ領域で毎回必出。「プレースホルダ」「バインド機構」がキーワード。応用情報技術者では、ブラインドSQLi（time-based / boolean-based）、Second-Order Injection、NoSQLインジェクション（MongoDB演算子注入）、ORMインジェクションまで踏み込む。情報処理安全確保支援士試験では、WAF（ModSecurity、AWS WAF、Cloudflare）のシグネチャ運用、サニタイズ vs エスケープ vs バインドの優先順位論述が問われる。

選択肢の発展補足

他選択肢の本来の対策対象：

• a → オープンリダイレクト：CWE-601、ホワイトリスト方式（許可ドメインリスト）+ 相対URL強制が定石
• b → ディレクトリトラバーサル：CWE-22、realpath()正規化＋ベースディレクトリ配下確認、Path APIのresolve+startsWith検証
• c → CSSインジェクション：データ漏えい（属性値の文字単位抜き出し攻撃）、CSP `style-src`制限＋ nonce/hash運用

現代の Web 脆弱性対策はDefense in Depth＋Secure by Default（フレームワーク・ORMが安全な書き方を強制）の方向。React・Vue は XSS、Rails の strong_parameters はマスアサインメント、Spring の `@PreAuthorize` は認可制御を標準化。SQLi も ORM 普及で激減したが、Raw SQL の混在箇所、動的テーブル名・カラム名、ORDER BY節は今もインジェクション残存リスクが高く、コードレビュー必須項目である。生成AI時代ではLLMコーディング補助がSQLi脆弱コードを生成する事例も観測されており、SASTツール（Snyk、Semgrep）でのCI/CDゲートがより重要になっている。