正解：ウ
各選択肢の解説
アデータベースに接続するアカウントの権限を、検索に必要な参照だけに絞る。
誤り。IPAの区分では保険的対策です。攻撃が成立したときに書き換えや削除まで 及ぶのを防ぐ、被害を小さくする手当てで、SQL文に命令を混ぜられる原因は 残ります。原因をなくすか、被害を減らすかで区別します。
イSQLの実行で発生したエラーの内容を、画面にそのまま表示しないようにする。
誤り。これも保険的対策です。エラー文は攻撃者がテーブル名などを探る 手がかりになるため隠す価値はありますが、入力値が命令として解釈される 組み立て方はそのままです。手がかりを減らすだけで、穴はふさがりません。
ウSQL文の組み立てを、すべてプレースホルダを使う方式に改める。
正解。プレースホルダを使うと、入力値は値として割り当てられ、SQL文の 構造の一部として解釈されなくなります。脆弱性の原因そのものをなくすので、 IPAは根本的解決に位置づけています。
エWebサイトの手前にWAFを置き、攻撃によく使われる文字列を含む通信を遮断する。
誤り。WAFは通信の中身を見て攻撃らしいものを止める、外側の防御です。 検知をすり抜ける書き方をされれば届いてしまい、アプリケーションの 作り方の欠陥は残ります。原因を直す対策の代わりにはなりません。
理解を深めるために
穴をふさぐ対策と、落ちたときの被害を減らす対策
IPAの「安全なウェブサイトの作り方」は、脆弱性ごとの対策を2つに分けています。 脆弱性の原因そのものをなくす根本的解決と、攻撃による影響の低減を期待できる 保険的対策です。道路の穴にたとえると、穴を埋めるのが根本的解決で、穴の手前に 注意の看板を立てたり、落ちてもけがが軽く済むようにしたりするのが保険的対策です。
なぜプレースホルダが根本的解決なのか
SQLインジェクションの原因は、入力値を文字列としてSQL文に連結するため、 入力に混ぜられた記号や命令がSQL文の一部として解釈されてしまうことです。
- プレースホルダは、SQL文の形を先に決め、入力値は後から「値」として割り当てる
- そのため入力に何が書かれていても、SQL文の構造は変わらない
- IPAは、値の割り当てをデータベースエンジン側で行う静的プレースホルダを、 原理的に脆弱性の余地がない方式として望ましいとしている
なお、やむを得ず文字列連結で組み立てる場合に、データベースエンジンのAPIで リテラルを正しく生成する（エスケープする）ことも、IPAは根本的解決に含めています。 「エスケープは保険的」と覚えるのは誤りです。
混同しやすいものとの違い
| 対策 | 区分 | 何に効くか |
|---|---|---|
| プレースホルダの使用 | 根本的解決 | 入力値が命令として解釈される原因をなくす |
| DBアカウントの最小権限 | 保険的対策 | 攻撃が成立したときの被害の範囲を絞る |
| エラーメッセージを表示しない | 保険的対策 | 攻撃者が手がかりを得にくくする |
| WAFによる遮断 | 外側の防御 | 攻撃らしい通信を止めるが、欠陥は残る |
保険的対策にも意味はありますが、根本的解決の代わりにはなりません。 委託先に求める順番は、まず原因をなくすこと、そのうえで被害を減らす手当てを重ねることです。