SQLインジェクションの試験問題への適用
検索画面・バッチ・並び替えの事例から、入力がSQLへ渡る経路を追います。基本を確認した後、各事例で残る原因と補助対策を区別して判断します。
この単元で学ぶこと
- 入力が命令として解釈される原因を説明する
- 処理する場所に合う根本対策を選ぶ
- 補助対策の効果と限界を区別する
- 事例から修正と確認の手順を組み立てる
本文解説
著者名で検索できない事例 図書システムで O'Neil を検索するとエラーになるとします。入力を引用符で囲んでSQLへ直接つないでいれば、名前の記号が区切りと衝突した可能性があります。人名から記号を取り除く修正では正しい検索を壊します。WHERE author = ? の値へ名前をバインドし、命令構造と分けます。
値として扱われる結果 books表にAliceとBobの著者だけがいる例で考えます。著者名を完全一致で比較するSQLへ Alice OR Bob を一つの値としてバインドすると、該当する名前はないので0件です。値中のORを演算子に変えないことが大切です。Aliceという値なら該当するAliceの行を返し、通常機能も保ちます。
並び替えの設計を直す priceとtitleの二つだけを選べる画面でも、HTTPの送信値は変更できます。サーバー上でpriceを固定の価格列、titleを固定の書名列へ対応付け、未知の値を拒否します。値用の?を列名の置換と考えず、命令の構造はアプリ側が選びます。hiddenにSQL全文を保存して送る設計も避けます。
会員番号の検証 番号は正の整数という仕様なら、受信した値の型や範囲をサーバーで検証します。ブラウザの数値欄は使いやすさを助けても、直接送信される値まで制限できません。仕様に合う値をSQLへバインドし、仕様外の値は決めたエラーとして扱います。入力検証とバインドを二者択一にしません。
保存した取引先名を使うバッチ 以前保存した名前を取り出し、集計用SQLへ直接連結するバッチも確認対象です。保存時に正常な名前だったとしても、その中の記号をSQL構造へ取り込んではいけません。データの保管場所ではなく、次の処理が何として解釈するかを追い、バッチでも値をバインドします。
参照専用でも残る危険 検索アカウントに更新権限がない場合も、本来の検索条件を変えられれば不要な情報を読み出されるおそれがあります。権限縮小だけで漏えいを否定しません。安全な組立てを直した上で、必要な表や操作への権限に絞り、被害を限定する対策を重ねます。
エラーとWAFの読み方 ブラウザへSQL文やテーブル名を返していたら、外部には一般的なエラーを示し、詳細は閲覧を限定した記録へ残します。WAFの検知がゼロでも、未試行や未検知の可能性があります。表示を隠すことや検知結果を、脆弱な連結処理がない証拠にしないようにします。
修正結果を判定する 対象の検索・更新・バッチのSQL構築箇所を確認し、正常値、正当な記号、仕様外の値の結果を比べます。値と構造の分離、構造部分の許可値、最小権限、エラー処理を順に確かめます。HTML表示もあるならSQL対策とは別に出力文脈を確認し、全用途に一種類のエスケープを流用しません。
図解
重要ポイント
- SQLの命令構造と入力値を分離する。
- 列名や並び順は許可した固定の構造へ対応付ける。
- 最小権限・WAF・エラー制御は根本対策に重ねる。
間違えやすい点
- HTMLエスケープをSQLのバインドの代用にしない。
- HTTPS・ORM・hiddenという名前だけで安全としない。
- 保存済みの値や参照専用権限も無条件に信用しない。
用語解説
- SQLインジェクション
- 入力がSQLの構造として取り込まれる不備を悪用し、意図しないDB処理を行わせる攻撃。
- プレースホルダ
- SQLの雛形に設ける、値を割り当てる位置を示す記号。
- バインド
- プレースホルダへ実際の値を割り当てる操作。
- 許可リスト
- 受け付ける値や構造を明示し、それ以外を許可しない方式。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。